Www.ganymede.com

Ganymede: Welcome to Ganymede Software!
Ganymede Joins
Forces with Mission
Critical Software and
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
Ganymede's new
products ensure that
applications will work
well from the End
User's perspective
Welcome to Ganymede Software!

Ganymede Software is the industry leader in end-to-end monitoring and testing
from the application layer. Its award-winning technologies solve the day-to-day
challenges of enterprise performance management.
Enterprise performance management means managing the performance of
clients, servers, applications, and the network as an integrated system in order to
deliver and maintain reliable, predictable application performance.
Download Qcheck!
Ganymede Software's
Free utility for testing
network performance
http://www.ganymede.com/ (1 of 2) [3/14/2000 8:15:32 AM]
Copyright 2000 Ganymede Software Inc. -- Privacy Statement
Ganymede: Welcome to Ganymede Software!
http://www.ganymede.com/ (2 of 2) [3/14/2000 8:15:32 AM]
Ganymede: Search Ganymede
Search Ganymede
Search:
Go!
Search our site by keywords to find what you are looking for.
Separate multiple keywords with a space.
http://www.ganymede.com/search.cgi [3/14/2000 8:15:37 AM]
Ganymede: Site Map
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
Site Map
Ganymede's new
well from the End
User's perspective
The Leader in Network Performance Management Solutions
What's in a name?
Career Opportunities at Ganymede
Welcome to our Newsletter!
Download Qcheck!
Ganymede Software's
network performance
Ganymede Software
The Performance Monitor Archive
Ganymede Products
The Industry Standard for Measuring Performance
http://www.ganymede.com/sitemap.phtml (1 of 4) [3/14/2000 8:15:40 AM]
How Does Chariot Work?
Chariot Solutions
Chariot can give you peace of mind!
Chariot Technical Specifications
Test Labs Using Chariot
Ganymede: Site Map
Try Chariot for Free!
Monitoring and Troubleshooting Application Performance
How Does Pegasus Work?
Pegasus Solutions
Pegasus Summary of Features
Pegasus Technical Specifications
Nervous About Enterprise Performance?
What is causing your application performance problems?
Pegasus Development Partners
The Performance Endpoint... A workhorse you can count on!
Performance Endpoints and Chariot
Performance Endpoints and Qcheck
Performance Endpoints and Pegasus
Performance Endpoint and the Cobalt RaQ
Operating System and Protocol Support
Download Performance Endpoints
Creating Custom Application Scripts
Ganymede Software Download Registration Form
Application Scanner Technical specifications
Sales Contacts
Dedicated to Ongoing Support
Chariot Technical Support
Chariot Service Updates
Chariot FAQ
Chariot Specifications
Ganymede: Site Map
Chariot Documentation
Chariot Third Party Updates
Chariot Tools and Utilities
Chariot Testing Tips
Pegasus Technical Support
Pegasus Service Updates
Pegasus FAQ
Pegasus Specifications
Pegasus Documentation
Pegasus Third Party Updates
Endpoint Technical Support
Endpoint Service Updates
Endpoint FAQ
Endpoint Specifications
Endpoint Documentation
Endpoint Third Party Updates
Application Scanner Technical Support
Application Scanner FAQ
Application Scanner Documentation
Application Scripts Techncial Support
Application Script Library
Application Script FAQ
Application Script Documentation
Technical Support Download Center
Ganymede Software Education
Ganymede Software Training Overview
Ganymede: Site Map
Directions to Ganymede
Local Hotels
Ganymede Software Professional Services
Ganymede Service Offerings
Ganymede Press Room
Press Releases
Case Studies
Ganymede in the News
Literature
Brochures
White Papers
Ganymede: Networking Resource Links
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
Ganymede's new
well from the End
User's perspective
Download Qcheck!
Ganymede Software's
network performance
Networking Resource Links

ATM Information
Links and resources related to Asynchronous Transfer Mode
Companies
Companies and other groups providing Networking products and services
Ethernet
Links and resources for Ethernet, Fast Ethernet and Gigabit Ethernet
Frame Relay
Frame Relay Resources
Hot Topics
Hot Networking Topics
IP Quality of Service
Links and resources for IP Quality of Service
IP Switching
IP Switching Resources
http://www.ganymede.com/netlinks.phtml (1 of 2) [3/14/2000 8:15:42 AM]
Ganymede: Networking Resource Links
ISDN Information
Links and resources related to ISDN Networking
Multimedia/VoIP
Links and resources for Multimedia and Voice over IP
Network Management
Resources related to Network Management
Network Performance
Network Performance Resources
Periodicals
Periodicals and Trade Journals covering Networking and Information
Technology
Policy Based Network Management
Policy Based Network Management Resources
http://www.ganymede.com/netlinks.phtml (2 of 2) [3/14/2000 8:15:42 AM]
Ganymede: Ganymede Corporate Events
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
Ganymede Corporate Events

We will be exhibiting and/or speaking at a variety of events over the coming
months. Come and visit us! We would love the chance to meet you and learn
what you need to deliver reliable, high-performance networked applications to
your end users.
Ganymede's new
well from the End
User's perspective
Download Qcheck!
Ganymede Software's
network performance
Comnet 2000
Washington, DC January 25-27
http://www.ganymede.com/events.phtml (1 of 2) [3/14/2000 8:15:48 AM]
Ganymede: Ganymede Corporate Events
http://www.ganymede.com/events.phtml (2 of 2) [3/14/2000 8:15:48 AM]
Ganymede: Contacting Ganymede Software
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
Ganymede's new
well from the End
User's perspective
Download Qcheck!
Ganymede Software's
network performance
Contacting Ganymede Software

Ganymede Software
1100 Perimeter Park Drive
Suite 104
Morrisville, NC 27560
Main Phone: 888-GANYMEDE (426-9633) or 919-469-0997
Sales Phone: 888-GANYMEDE (426-9633) Option #5
Tech Support Phone: 888-GANYMEDE (426-9633) Option #6
Fax: 919-469-5553
Company Internet Email: info@ganymede.com
Technical Support Email: support@ganymede.com
Career Opportunities Email: employ@ganymede.com
Webmaster Email: webmaster@ganymede.com
We are located near RDU International Airport off Airport Blvd. Our office
building is located at 1100 Perimeter Park Drive, Suite 104, approximately 1
http://www.ganymede.com/contact.phtml (1 of 2) [3/14/2000 8:15:50 AM]
Ganymede: Contacting Ganymede Software
mile off I-40 in Perimeter Park West.

Click here for a detailed map with driving directions from MapQuest.
From I-40 East
Take exit 284a (Airport Blvd West). At the top of the ramp, take a right to
merge onto Airport Road. Go straight through the stoplight and continue
on Airport Blvd.
From I-40 West
Take exit 284. At the top of the ramp, take a left onto Airport Blvd. Drive
over the I-40 overpass and continue on Airport Blvd. through two
stoplights.
From RDU Airport
Follow the airport exit signs towards I-40 West/Durham. This will put you
on Airport Blvd. After leaving the airport, continue on Airport Blvd. over
the I-40 overpass and through three stoplights.
You will pass a shopping mall on your right. The next stoplight will be Perimeter
Park Drive. Go straight through this light and take the first right into a parking
lot. As you enter this parking lot you will be facing the entrance to our building
(Suite 104).
http://www.ganymede.com/contact.phtml (2 of 2) [3/14/2000 8:15:50 AM]
Ganymede: Ganymede Software
Ganymede Software is the industry leader in end-to-end monitoring and testing

from the application layer. Its award-winning technologies solve the day-to-day
challenges of enterprise performance management.
Enterprise performance management means managing the performance of
clients, servers, applications, and the network as an integrated system in order to
deliver and maintain reliable, predictable application performance.
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
http://www.ganymede.com/company/index.phtml (1 of 2) [3/14/2000 8:15:58 AM]
Ganymede: Ganymede Software
Check out Careers at

Ganymede
http://www.ganymede.com/company/index.phtml (2 of 2) [3/14/2000 8:15:58 AM]
Ganymede: Ganymede Products
From the recognized leader in network performance management... Ganymede

Software presents its Chariot and PegasusTM family of products for planning,
testing, monitoring and troubleshooting in your unique network environment!
Download Qcheck!
Ganymede Software's
network performance
Ganymede Software designed its products to be tightly linked and produce the
same types of performance metrics. Common technology and metrics means:
Ensuring smooth application and network deployment by testing new
technology before it is rolled out to your users
Improving problem-solving techniques and preventing problems before
they occur
Leveraging critical network and systems skills in your enterprise, better
utilizing your staff
Decreasing overall organizational expenses by streamlining your network
environment with integrated performance management tools.
Whether you're responsible for planning, implementation, troubleshooting, or
ongoing operations, you'll appreciate the versatility, affordability and ease of use
of Ganymede Software's products!
http://www.ganymede.com/products/index.phtml (1 of 2) [3/14/2000 8:16:04 AM]
Ganymede: Ganymede Products
http://www.ganymede.com/products/index.phtml (2 of 2) [3/14/2000 8:16:04 AM]
Ganymede: Dedicated to Ongoing Support
Ganymede Software's products are designed and developed with the highest
quality standards and are rigorously tested in laboratory and field environments.
Our dedication to providing you a quality product continues long after your
purchase.
Ganymede Software helps you get the most from your products by providing
you the highest caliber of customer support. Our technical support staff is
comprised of industry veterans, with a wide range of experience in a variety of
computing and networking environments. They can answer your product
questions, and recommend strategies and techniques to help you create custom
performance monitoring and test environments.
Our technical support staff is available via telephone Monday through Friday,
from 9:00AM - 6:00PM Eastern Time (excluding holidays). You may also
contact Technical Support via e-mail and facsimile at the contact numbers listed
below.
Support Contact Information:
Email: support@ganymede.com
Phone: 888-GANYMEDE (426-9633) Option #6
Phone: (outside U.S.) 919-469-0997 Option #6
http://www.ganymede.com/support/index.phtml (1 of 2) [3/14/2000 8:16:09 AM]
Ganymede: Dedicated to Ongoing Support
Fax: 919-469-5553
http://www.ganymede.com/support/index.phtml (2 of 2) [3/14/2000 8:16:09 AM]
Ganymede: Ganymede Press Room
Ganymede's Press area is where you'll find the most recent press releases,
articles and reviews on our company and products. While you're here, take a
moment to read our customer testimonials and case studies.
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
http://www.ganymede.com/pressroom/index.phtml (1 of 2) [3/14/2000 8:16:14 AM]
Ganymede: Ganymede Press Room
http://www.ganymede.com/pressroom/index.phtml (2 of 2) [3/14/2000 8:16:14 AM]
Ganymede: Literature
The Ganymede Literature Center contains the .pdf versions of our entire product
and company literature library as well as .pdf versions of our popular white
papers.
Policy-Based
Management Paper
http://www.ganymede.com/literature/index.phtml [3/14/2000 8:16:19 AM]
Ganymede Software
Registration for Ganymede Product Brochures

(items marked with an * are required)
*First Name:
*Email Address:
Title:
*Company:
*Address:
Address:
*City:
http://cgi.ganymede.com/brochures.phtml (1 of 2) [3/14/2000 8:16:38 AM]
*Last Name:
Ganymede Software
*State:
*Zip/Postal Code:
*Telephone Number:
Fax Number:
Submit Request
http://cgi.ganymede.com/brochures.phtml (2 of 2) [3/14/2000 8:16:38 AM]
Ganymede Software
Registration for Ganymede White Papers

*First Name:
*Email Address:
Title:
*Company:
*Address:
Address:
*City:
http://cgi.ganymede.com/whitepapers.phtml (1 of 2) [3/14/2000 8:16:41 AM]
*Last Name:
Ganymede Software
*State:
*Zip/Postal Code:
*Telephone Number:
Fax Number:
Submit Request
http://cgi.ganymede.com/whitepapers.phtml (2 of 2) [3/14/2000 8:16:41 AM]
Ganymede: Press Releases
Press Releases
Ganymede Joins Forces with Mission Critical Software and NetIQ Mission Critical and NetIQ Agree to Merger of Equals
Press release - Monday February 28, 2000
Ganymede's New Products Ensure That Applications Will Work Well
From the End User's Perspective
Ganymede Software Appoints Former Platinum Technology Executive to
Vice President of Marketing
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
Press release - Monday December 13, 1999

Ganymede introduces Qcheck: the ultimate utility for testing network
response time, throughput and streaming performance
Press release - Monday October 18, 1999
Ganymede Software Adds Two New Visionaries to its Board of Directors
Press release - Tuesday September 21, 1999
Ganymede's Chariot Selected by CMP to Power Suite of Network
http://www.ganymede.com/pressroom/releases.phtml (1 of 4) [3/14/2000 8:16:45 AM]
Performance Testing Benchmarks

Press release - Monday September 20, 1999
Ganymede Software Adds Three New Resellers to Global Channel Reseller
Program
Press release - Tuesday August 31, 1999
Interpath to Implement Ganymede's Pegasus Software to Monitor the
Performance of Network and Virtual Private Applications (VPAs)
Press release - Monday August 23, 1999
Learn How to Get Started with Policy-Based Management: Free White
Paper Available from Ganymede Software!
Press release - Wednesday August 18, 1999
Ganymede's New Pegasus Software is the First Line of Defense for
Application Performance Problems
Press release - Monday August 9, 1999
Discover the Impact of ERP Applications on the Network: Free white paper
available from Ganymede Software!
Press release - Wednesday June 2, 1999
3Com Relies Upon Ganymede Software's Chariot to Test and Demonstrate
How 3Com Products Will Perform in Real-World Environments
Press release - Tuesday June 1, 1999
Ganymede Software Introduces the Only Solution for Determining That a
Network is "VoIP-Ready"
Press release - Sunday May 23, 1999
Ganymede Software Introduces New Solution Which Enables Service
Providers to Test and Monitor End-to-End Service Performance
Press release - Tuesday May 18, 1999
Concord, Ganymede to Support Orchestream's Live Demo of Policy-Based
Network Management at N+I 99
Press release - Monday May 10, 1999
Concord Teams with Ganymede to Provide End-to-End Network

Performance Measurements
Press release - Monday May 3, 1999
Ganymede Software Names New Chief Technology Officer and Vice
President of Marketing
Press release - Tuesday April 13, 1999
Red Hat Software to Incorporate Ganymede Software Performance
Endpoints into Next Release of Red Hat Linux
Press release - Monday March 22, 1999
Ganymede Software's New Pegasus Software Enables IT Managers to
Pinpoint Cause of Performance Problems
PC Week Names Ganymede Software One to Watch in 1999
Press release - Tuesday March 9, 1999
Ganymede Software's Performance Endpoint Earns Novell "Yes, Tested
and Approved" Certification
Market Leaders Announce Results of First Forum for Application
Performance and Service-Level Management Industry
Ganymede Software Strengthens Partnership with Baan Company:
Completes BaanCAPPS Certification
Ganymede Software's Chariot Testing System Wins 1999 Hot Products
Award and World Class Award
Press release - Tuesday January 26, 1999
Ganymede Software Announces Strategy for Making Reliable, Predictable
Application Performance a Reality
Press release - Monday January 11, 1999
Now Measure the Peformance of Any Application on the Network With

Ganymede Software Products
Press release - Monday January 11, 1999
Ganymede: Case Studies
Case Studies
Power- Network Deployment and
Performance Validation
Automotive Manufacturer - Network
Migration
Cylink Corporation Validates
Performance
Duke University - Network Migration
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
Duke University - Wireless Network Test

Government - Network Deployment
NIA - PNNI Interoperability Test
RealWorld Networks - Frame Relay Mgt.
Products Test
Reinsurance company - Application Rollout
SaraLee Knit Products - Hardware.Service Provider Evaluations
http://www.ganymede.com/pressroom/casestudies.phtml (1 of 2) [3/14/2000 8:16:51 AM]
Ganymede: Case Studies
Xedia Corp. Drives Home Marketing
http://www.ganymede.com/pressroom/casestudies.phtml (2 of 2) [3/14/2000 8:16:51 AM]
Ganymede: Ganymede in the News
Ganymede in the News

Ganymede Joins Forces with Mission Critical Software and NetIQ Mission Critical and NetIQ Agree to Merger of Equals
Ganymede Acquisition - Merger Information
Pegasus Now Checks The Network And Its Applications
Internet Week - 2/14/2000
Application-monitoring tools could solve performance problems. Or they
could just add finger-pointing to your troubles
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
Computerworld 2/3/2000
Ganymede to boost network performance offerings
InfoWorld 2/4/2000
Information Week - "Smooth Operations Depend on Smart Testing Plans"
Article dated 1/24/2000
A fine steed, indeed Ganymede Software's Pegasus 2.1 comes in a winner
Network World 12/20/1999
Pegasus Gets Net Monitoring off the Ground
http://www.ganymede.com/pressroom/articles.phtml (1 of 3) [3/14/2000 8:16:54 AM]
PC Week 11/29/1999
Pegasus Lets You Know Your Apps the Way Your Users Do
Network Computing 11/29/1999
Take Your LAN For A Test Drive -- Ganymede's Chariot Measures The
Effects Of Network Applications Before You Install Them
InformationWeek 11/15/1999
Network Fire PreventionYou'll need a tool kit that includes performance
monitoring gear...
Religious Wars End; Active and Passive is the Answer
Ganymede tools rev network troubleshooting
PCWeek 08/09/1999
Users Shun Platforms for App Management
InternetWeek 08/09/1999
New Software Measures Real-Time Apps' Impacts
Sounding Board 07/15/1999 (requires login)
Feds track far-flung networks with monitoring tools
Federal Computer Week 06/02/1999
Ganymede App Measures Voice Impact On IP Networks
InternetWeek 05/31/1999
Ganymede System Tests Networks For VoIP Readiness
Internet Telephony 05/25/1999
Tools for Managing the New Enterprise
Prepared to be Proactive--Users find new performance tools that help them
anticipate end-user complaints and nip net problems in
Network Managers Get User's-Eye View

PC Week Names Ganymede Software One to Watch in 1999
Ganymede: Ganymede Software Acquisition-Merger Information
Ganymede Acquisition Information

Ganymede to be acquired by Mission Critical Software, then merge with
NetIQ - Press Release
Frequently Asked Questions
Summary Sheet
Slides

Ganymede
http://www.ganymede.com/download/merger/mergerinfo.html [3/14/2000 8:16:56 AM]
Ganymede: The Leader in Network Performance Management Solutions
The Leader in Network Performance Management Solutions
Our Past...
In 1995, four partners recognized an unfulfilled need for the end-to-end testing
and monitoring of enterprise networks. Bringing extensive experience in
network design, software development and marketing of high technology
products, these four visionaries founded Ganymede Software. They chose to
locate their new company in the Research Triangle Park region of North
Carolina.
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
Early in its development, Ganymede Software forged relationships with

technology incubators and private investors that recognized the company's
innovation and potential for success. Ganymede Software's first product,
Chariot, was quickly praised by major computer trade publications. It wasn't
long before Ganymede Software expanded its product line based on the
Chariot architecture to add power and flexibility to their performance
management solution.
http://www.ganymede.com/company/overview.phtml (1 of 4) [3/14/2000 8:16:59 AM]

Ganymede
Our Present...
Today, Chariot is the industry standard for network performance testing
software and PegasusTM is poised to become standard issue for enterprise
network managers.
In just a few short years, Ganymede Software has evolved from a small start-up
company to a highly acclaimed, award-winning, multi-product company with an
international presence.
Ganymede Software's products have earned significant recognition in the
industry, as evidenced by these recent awards:
1999 Hot Products Award - Chariot, Data Communications
World Class Award - Chariot, Network World
Networked Multimedia Award - Chariot, Desktop Video Communications
Show
Best of Show - Pegasus, ComNet 1998
New Product of the Year - Pegasus, Council for Entrepreneurial
Development, RTP
Top 15 Companies to Watch in 1999 - Ganymede Software, PC Week
March, 1999
Our Future...
Dedicated to their original vision of providing IT organizations all over the
world with powerful tools that provide decision support and help them better
manage network performance, the four original founders remain involved in
Ganymede Software's ongoing technology development, growth, and strategic
direction.
An industry-leading product line, strategic partnerships, an impressive and
expanding client roster, and rapidly evolving channels for bringing cutting-edge
technologies to market are all factors that position Ganymede Software for
continued stellar success!
Technology Overview
Ganymede Software Inc. provides network performance management solutions
that help network managers deliver reliable, high-performance networked
applications.
Defining Network Performance Management...

Traditionally, network management meant focusing on individual devices,
isolated disciplines, and independent network links.
But Ganymede Software developed its product line based on an innovative
concept: end-to-end network performance management. We help you manage
the performance of applications, clients, servers, and the network as a complete,
integrated system, not as a collection of individual components.
Integrating Information Technology Life Cycle Stages...

Ganymede Software's products integrate the stages of the IT life cycle, from
planning through deployment through ongoing monitoring.
For testing network performance in the planning and deployment stages...
Chariot
For monitoring network response time, throughput, and connectivity in
the ongoing monitoring stage... PegasusTM
For creating scripts that emulate an application transaction... Application
Scanner
Understanding Your Unique Environment...
Ganymede Software recognizes that no two networks are the same, and that you
need tools that work within your own custom environment. That's why we have
designed our products to be compatible with 16 different operating systems from
MVS to Windows, and to run on six different network protocols.
Today, more than 1000 customers and independent testing labs all over the
world have chosen Ganymede Software's products for their own unique
environments.
Partnering with Other Leading Companies...

Ganymede Software is dedicated to technology integration efforts with a
number of companies that develop networking equipment and supporting tools
for network management.
Our strategic partnerships with Cisco Systems, Concord Communications,
DeskTalk, Hewlett-Packard, Micromuse, Red Hat, and others bring you the best
applications and system management tools available.
Our partner companies recognize the strength and versatility of Ganymede
Software's products; in fact, our Performance Endpoints are currently being
shipped with Red Hat Linux and Cobalt RaQ2.
Ganymede Software is based in Morrisville, North Carolina. Telephone:
919-469-0997.
Ganymede, Ganymede Software, and Chariot are registered trademarks of
Ganymede Software Inc.
Pegasus is a trademark of Ganymede Software Inc.
Other names are trademarks of their owners.
Ganymede Software Inc. 1999
Ganymede: What's in a name?
What's in a name?
The dictionary gives three definitions of Ganymede:
1. A Trojan boy who Zeus carried away to be cup bearer to the gods
2. A young man who serves drinks
3. The fourth moon of Jupiter, one of the largest satellites in the solar system
Ganymede... The Company Name
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
So why did we choose Ganymede for our company name?

1. It wasn't taken. (Finding a name that isn't already trademarked is tough)
2. It had a nice "ring" to it.
3. It flows well.
4. Tending bar for gods seemed like an interesting job. (Imagine when they
come in at the end of the day to unload their problems!)
5. If you're going to be named after a moon, you might as well pick one big
enough to be a planet.
http://www.ganymede.com/company/ourname.phtml (1 of 3) [3/14/2000 8:17:03 AM]

Ganymede
Ganymede... The Satellite

1. Ganymede is the largest moon of Jupiter and is the largest in our solar
system, with a diameter of 5,262 km (3,280 miles).
2. Ganymede is most likely composed of a rocky core with a water/ice
mantle and a crust of rock and ice.
3. It has no known atmosphere. It has mountains, valleys, craters, and lava
flows.
4. Ganymede is mottled by both light and dark regions. It is heavily cratered,
especially in the dark regions, implying ancient origin. The bright regions
show a different kind of terrain, grooved with ridges and troughs. These
features form complex patterns, have a vertical relief of a few hundred
meters, and run for thousands of kilometers. The grooved features were
apparently formed more recently than the dark cratered area, perhaps by
tension from global tectonic processes. The real reason is unknown,
however local crust spreading does appear to have taken place causing the
crust to shear and separate.
Ganymede Statistics
Discovered by ..... Simon Marius Galileo Galilei
Date of discovery ......................... 1610
Mass (kg) ............................. 1.48e+23
Mass (Earth = 1) .................... 2.4766e-02
Equatorial radius (km) .................... 2631
Equatorial radius (Earth = 1) ....... 4.1251e-01
Mean density (gm/cm^3) .................... 1.94
Mean distance from Jupiter (km) ...... 1,070,000
Rotational period (days) ................. 7.155
Orbital period (days) .................... 7.155
Mean orbital velocity (km/sec) ........... 10.88
Orbital eccentricity ...................... 0.00
Orbital inclination ...................... 0.19
Visual geometric albedo ................... 0.42
Magnitude (Vo) ............................. 4.6
Ganymede: Career Opportunities at Ganymede
Career Opportunities at Ganymede

We're a software company, looking for employees who want to work hard, work
smart, take a lot of initiative, and have lots of fun. It's an environment of
excellence; apply only if that's the kind of environment where you thrive. You'll
find we offer competitive compensation and benefits. If you are interested in
applying for a job described here, send your cover letter and resume via fax,
email or hardcopy mail to:
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals

1100 Perimeter Park Drive, Suite 104
Fax: 919-469-5553
Email: employ@ganymede.com
Current Openings:
IS Manager
Hands-on position for someone with extensive experience implementing
the network and database needs of an entrepreneurial software
development company. Supervisory experience required.
http://www.ganymede.com/company/careers.phtml (1 of 3) [3/14/2000 8:17:06 AM]

Ganymede
GUI Software Developer
Design, develop, and unit test code in a demanding environment that

requires excellence.
Inside Business Development Representative
As an Inside Business Development Representative, you will have the

opportunity to influence the financial growth of Ganymede Software by
turning leads into qualified opportunities and generating new business for
Territory Managers.
MVS Developer
Work closely with engineering and customers to develop high-quality

software to measure network and application performance in complex
networks.
Program Manager, Channels
Work with Ganymede's corporate reseller partners to help them become

successful in selling and supporting Ganymede products, plus develop
programs to enhance Ganymede's Software Maintenance offerings for its
direct and indirect customers: Manage the day-to-day business
relationships with Ganymede's major reseller partners. Develop
strategies/programs for each partner to create a win/win environment for
Ganymede and the partner. Develop strategies/programs that ensure
Ganymede software maintenance customers remain satisfied customers.
Program Manager, Professional Services
Delight our customers by leading the team that develops and manages
professional service offerings for our Application Performance
Management software products. You will be a key player in helping
Ganymede grow its professional service business.
Sales Coordinator
Work with Ganymede's worldwide sales and services organization to help

us provide the best service possible to our customers and distribution
partners. You will be a key resource in making our organization run
smoothly.
Technical Support Representative
Delight customers working with our enterprise performance management

software products. You'll be the expert that helps them answer their
questions and solve their problems.
Territory Manager - Western Region
Manage a geographic territory to meet sales revenue goals by working

with end user clients, networking vendors, and consultants/integrators.
Successful candidate will be able to sell directly into IS and network
divisions of Fortune 1000 companies.
User Interface Software Designer
Be responsible for maintaining UI usability, quality, and consistency

across Ganymede's software products and utilities.
Territory Manager - Eastern Region
Manage a geographic territory to meet sales revenue goals by working

with end user clients, networking vendors, and consultants/integrators.
Successful candidate will be able to sell directly into IS and network
divisions of Fortune 1000 companies.
Systems Engineer
Delight the customers working with our Enterprise Performance

Management software products. Youll be the expert that helps them
answer their questions and solve their problems.
Test Engineer (Software Exorcist)
Not just another testing job! Become a part of a professional community
in which testers command the respect they deserve. Work with a talented
group of engineers making a career of software testing.
Visiting us? Click here for a detailed map with driving directions from
MapQuest. For local directions, click here.
Ganymede: Welcome to our Newsletter!
Welcome to our Newsletter!

The Performance Monitor is a newsletter published every other month,
delivering valuable information on enterprise performance and other hot topics.
Click here to subscribe!
August 1999 Newsletter

Ganymede's Performance Monitor
newsletter for August 1999
June 1999 Newsletter
newsletter for June 1999
November 1999 Newsletter
newsletter for November 1999
http://www.ganymede.com/company/newsletter/index.phtml (1 of 2) [3/14/2000 8:17:12 AM]
Ganymede: Welcome to our Newsletter!
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
Ganymede
Check the Performance Monitor Newsletter Archive
http://www.ganymede.com/company/newsletter/index.phtml (2 of 2) [3/14/2000 8:17:12 AM]
Ganymede: The Performance Monitor Archive
The Performance Monitor Archive

The Performance Monitor is a newsletter published every other month,
delivering valuable information on enterprise performance and other hot topics.
August 1999 Newsletter
Ganymede's Performance Monitor newsletter for August 1999
June 1999 Newsletter
Ganymede's Performance Monitor newsletter for June 1999
November 1999 Newsletter
Ganymede's Performance Monitor newsletter for November 1999
http://www.ganymede.com/company/newsletter/archive/index.phtml (1 of 2) [3/14/2000 8:17:15 AM]
Ganymede: The Performance Monitor Archive
Ganymede Joins
Forces with Mission
NetIQ - Mission
Critical and NetIQ
Agree to Merger of
Equals
Ganymede
http://www.ganymede.com/company/newsletter/archive/index.phtml (2 of 2) [3/14/2000 8:17:15 AM]
Embedded Secure Document

The file http://www.ganymede.com/download/newsletter/899news.pdf is a secure document that has been embedded in this
document. Double click the pushpin to view 899news.pdf.
http://www.ganymede.com/download/newsletter/899news.pdf [3/14/2000 8:17:48 AM]
June 1999
(Point your browser to http://www.ganymede.com/html/

performancemonitor.htm if you would like to view the html
version of this newsletter)
Highlights from the June, 1999 edition of The Performance
Monitor are:
ERP application deployment How to make sure your
network is prepared. (See: http://www.ganymede.com/
html/june99.htm#debate)
Download a copy of Ganymedes FREE white paper,
ERP on the Wire, which demonstrates the impact of
running enterprise resource planning (ERP) application
across different WAN configurations. (See: http://
www.ganymede.com/erpwhite.htm)
Ganymede Software releases Chariot 3.1 - the only
solution that can determine whether a network can
support Voice over IP (VOIP). (See: http://
www.ganymede.com/html/june99.htm#press)
Join Ganymedes Referral Program and win big! (See:
http://www.ganymede.com/html/refer.htm)
We welcome all comments and would love to hear from you
about what you would like to see in future issues. If you do
not wish to continue receiving this newsletter, simply reply
and type Unsubscribe in the subject box and we will
promptly take you off our list.
Sincerely,
Aimee Dhus, Online Editor
Ganymede, Ganymede Software, and Chariot are registered trademarks of

Ganymede Software Inc. Pegasus is a trademark of Ganymede Software Inc. All
other names are trademarks of their ownmers.
Volume 2, Issue 3
How to control an ERP application deployment before it

controls you!
In order for companies to stay competitive, their users must
be productive. Many companies have come to rely on core
applications, such as enterprise resource planning (ERP)
applications, which must be up and running 24 hours a day,
seven days a week. When these applications experience poor
performance the results are costly. According to a recent
survey of 900 IT professionals in InformationWeek magazine,
the average cost for an enterprise application outage is nearly
$36,000 an hour. More than half of the surveys respondents
reported annual financial losses of $2.5 million or more due to
enterprise software outages. How could this have been
prevented? When developing, deploying and maintaining
applications, proper testing and monitoring throughout its life
cycle is essential.
In this article we discuss why up-front analysis and network
testing is critical when rolling out an application, such as ERP.
Proper communication between various IT groups and ongoing monitoring of the network after deployment are also
necessary to ensure reliable, predictable application performance.
Pre-deployment = Planning ahead
One of the biggest mistakes made when deploying an application is not anticipating the impact it will have on the network.
It is often assumed that the network will be able to handle the
new application just like it handles every other application.
Testing is often done in an isolated environment and does not
take into account scaling issues and other elements. How will
the application perform from a users perspective? Will more
bandwidth be needed? How will other existing applications be
impacted? These and other questions must be addressed
before an application is deployed onto a live network.
Enterprise resource planning (ERP) applications present
special benefits and hurdles to businesses today. ERP applications let companies link all their departments and operations
together into a single integrated information system. The

result is that business processes can become more efficient,
tighter controls on cost can be levied, better customer service
can be achieved and overall productivity will be improved.
But these improvements come at a premium as ERP applications are notoriously complex and usually require extensive
customization. Realizing these benefits often requires huge
investments in time and money.
What is often overlooked is the amount of traffic that can
occur after an ERP rollout. ERP applications generate a
largeamount of back-and-forth flows between the client and
server. In fact, a single activity such as adding an inventory
item may require an end user to fill out several forms. Just
think what could happen to the network as dozens or hundreds of users are all executing a mix of transactions simultaneously across an already busy network. Will the wide area
network links handle the additional load? These are the
images that keep IT managers up at night.
So how can a company ensure that its network is able to
handle an ERP application such as SAP R/3? There are a
number of tools currently on the market that can help assess
how an application will impact the network before it is
actually deployed. For example, modeling tools such as those
available from MIL3 or CACI enable a network manager to
create a mathematical model of the network and allow whatif scenarios to be developed without having to actually make
any modifications to the network. Modeling tools can be used
in an attempt to identify potential bottlenecks and approximate performance.
There are other tools, such as Ganymede Softwares Chariot,
that let an IT manager simulate a single user, or hundreds of
users, running a variety of applications and transactions to
and from any point on your network. Chariot sees the network
from the application layer, the way a user sees it, and can
generate real application traffic across the network to measure
end-to-end response time and throughput.
Working together
A recent InformationWeek article described IT organizations
as being like multilevel chessboards from which elements
are constantly being moved, added and deleted. The challenge
is to pay attention to the ramifications and opportunities, not
only on the two-dimensional level, but the levels above and
below. It is vitally important that various IT groups do not
operate in a vacuum. When developing, deploying or maintaining applications, all IT groups (application, systems,
desktop and network) must communicate with one another so
that each group is aware of new business and technology
opportunities, and to foster a collaborative rather than combative working environment. In some of the world-class IT
organizations we come in contact with, such as First Data,
NationsBank or Duke Power, the network management
groups within these companies have specific responsibilities
to work with the application developers to ensure a smooth
application rollouts. One of the things that each group can
work together on is ensuring that the application is validated
in a controlled environment before going live. Will the
network support the application? Will the application run
correctly? How will it impact other applications? These

questions must be answered in a controlled environment
before the user is exposed to the application. It is no longer
acceptable to treat users as guinea pigs by subjecting them to
untested changes or unstable systems.
Post-deployment: How to maintain reliable application
performance
Analysts say that most companies do not think of managing
their applications until after they have already been deployed.
More often than not, they are so consumed with getting the
software implemented across the enterprise that they forget to
think about how they plan on managing it should problems
occur or performance suffer. IT managers must be able to
recognize bottlenecks or failures before users start to complain. They need to know if a particular server is straining
under the weight of an application or if the network is experiencing slow response time.
From a network perspective, applications can be monitored in
different ways. In order to monitor performance the way a
user experiences it, an IT manager needs to measure end-toend from the application level. A system such as Ganymede
Softwares Pegasus is able to provide continuous monitoring
and track performance history and trends from the application
level. This information lets an IT manager know immediately
whether the problem is network or systems related. Network
components such as routers, switches and hubs can also
contribute to poor network performance which can ultimately
lead to a degradation in application performance. These
components often come with their own device management
software which allows you to track resource utilization. This
capability can be supplemented with protocol analyzers or
RMON probes that provide detailed frame data and singlesegment statistics. When a problem occurs, an alert is sent to
an alert manager (from companies such as HP Openview,
Micromuse or Tivoli). Alert managers receive and process
alerts from various agents throughout the network. Advanced
alert managers will also correlate the alerts to eliminate
redundant information and point to the root cause of the
network problem.
In order to maintain consistent application performance, an IT
manager should use the same set of metrics across the entire
application life cycle. From what-if analysis, to deployment to
long-term trending or SLA management, using the same set of
metrics will let an IT manager compare apples-to-apples
across different tasks. Reliable application performance is
vital for businesses to stay competitive in the marketplace.
Those IT organizations that fail to have a repeatable process
for developing and maintaining applications over their life
cycle will cause their companies to fall behind in the race to
enter new markets.
As a footnote, Ganymede recently conducted a series of tests
using Chariot to demonstrate the impact of running enterprise
resource planning (ERP) application across different WAN
configurations. The findings were presented in a white paper
titled: ERP on the Wire. To download a free copy of the
white paper, see http://www.ganymede.com/erpwhite.htm.
Join Ganymedes Referral Program

At Ganymede Software, we feel fortunate to have such
satisfied and loyal customers. We would like to thank you by
rewarding you when you refer us to your colleagues who may
have a similar need for Chariot or Pegasus. For more information see http://www.ganymede.com/html/refer.htm
Technologies from Ganymede and Shunra work well

together when testing the impact of new hardware or
applications
From time to time we will tell you about interesting
products or services that provide a good fit with Ganymedes
technology. Once such product is The Cloud from Shunra
Software, Ltd.
The Cloud is a software tool that enables you to test your
networking products under all possible WAN conditions.
The Cloud allows you to test both hardware and any OS
software in an endless variety of network configurations.
The Cloud does this using a unique Network Emulation
methodology. It uses your local network infrastructure and
turns it into a WAN. The Cloud does not record or generate
traffic, but rather emulates the WAN pipe. The Cloud gives
its user complete control over parameters of the pipe. These
parameters include latency, packet loss, bit error rate, IP
fragmentation, Out of order packets, network congestion and
more.
The Cloud and Chariot compliment each other very well. As
mentioned in the previous article about ERP deployment,
these two technologies (Chariot and The Cloud) were used
together to demonstrate the impact ERP applications can have
on the network. Using The Cloud you can emulate a variety
of WAN links and conditions. With Chariot you can drive
different types of traffic across these simulated links and
record the results to determine in advance how an application
will perform under these conditions. In this way you can
evaluate and define actual WAN bandwidth needs.
For a fully functional, 30-day evaluation of The Cloud, visit
Shunras web site: http://shunra.com.
For more information about Chariot, see http://
www.ganymede.com/html/chariot.htm
New Chariot Training Classes now Available

Ganymede Software is now offering training classes for
Chariot in both our Research Triangle Park and San Jose
locations. These courses are designed to enable the user to get
the most out of their product investment by providing a solid
background in Chariot fundamentals, reinforced by hands-on,
real-world exercises. To receive a schedule or to sign-up
for one of these training classes, send an email to
edu@ganymede.com or call 1-888-426-9633 ext. 301 to
speak with Susan Elek.
Ganymede Softwares Chariot 3.1 introduces the only

solution for determining that a network can support Voice
over IP (VoIP); Ganymede announces three new partnerships with Cobalt Networks, Concord Communications and
Red Hat.
On May 24th, Ganymede Software introduced the only
solution for evaluating the network performance of multimedia applications with the release of Chariot 3.1. Now with
support for jitter and the RTP component of H.323, Chariot
3.1 enables systems integrators and IT managers to ensure
that networks can support Voice over IP (VOIP) and other
multimedia applications without impacting business-critical
applications. Chariot 3.1 also includes an Application Programming Interface (API), which enables systems integrators,
systems/network management software vendors, and test labs
to integrate Chariots end-to-end measurements with other
testing and management solutions. See: http://
www.ganymede.com/html/chariot_3-1.htm.
On May 18th, Ganymede and Cobalt Networks announced that
they are providing a solution for service providers to test and
monitor end-to-end service performance. Cobalts RaQ server
appliances can now serve as an endpoint for use with
Ganymedes Pegasus performance monitoring system and
Chariot performance testing tool. Service providers can use
the Cobalt RaQ servers in conjunction with Ganymedes
products to monitor service level agreements and to predict
and verify the impact of network changes. See: http://
www.ganymedesoftware.com/html/cobalt.htm
On May 3rd, Ganymede and Concord Communications
announced that Concord will incorporate end-to-end performance measurements from Ganymedes Pegasus performance
monitor in the next release of its Network Health reporting
and analysis software. The ability to combine end-to-end
performance statistics from Pegasus with a comprehensive
analysis of individual network components enables Concord
to provide a complete view of network performance. This
perspective will benefit service providers and IT managers
alike in their efforts to monitor service level agreements and
to address network performance issues. See: http://
www.ganymede.com/html/concord5_99.htm
On March 22nd, Ganymede announced that Red Hat will

distribute Ganymedes performance endpoints on the Application CD that will ship in the next release of Red Hat Linux.
These endpoints are software agents used by Ganymedes
Chariot and Pegasus products to measure the network performance of applications. This collaboration gives Internet
Service Providers (ISPs) and corporations an easy way to test
and monitor the performance of networks with Linux servers
installed. See: http://www.ganymede.com/html/redhat.htm
In the
News
Ganymedes Chariot 2.2 was recently awarded Product of
the Year from Network Magazine! In addition, Ganymede
has received a lot of coverage in the press.
Network Magazine: 1999 Products of the Year Award
Winners. Ganymede Softwares Chariot 2.2 was awarded top
honors in the category of Systems management. Each award
winner was selected by the readers of Network Magazine as
being outstanding in their respective categories. See: http://
www.networkmagazine.com/magazine/archive/1999/05/
9905poy.htm#18
InternetWeek: Ganymede app measures voice impact on IP
networks. This is a great article covering the new release of
Chariot 3.1, which enables IT managers to determine how
multimedia applications such as voice over IP (VoIP) will
impact their networks production environment. See: http://
www.techweb.com/se/directlink.cgi?INW19990531S0046
Network World: Prepared to be proactive. Ganymedes
customer, NationsBank, is featured in this article about how
IT managers are able to find performance management tools
to help them anticipate end-user complaints and nip problems
before they start. See (login may be required): http://
www.nwfusion.com/netresources/0322proactive.htm.
Network World: Network Managers get users-eye view.

Ganymede Software was featured in this article about several
vendors who are releasing software that shows the response time
end users are receiving and why this is an important measurement. See (login may be required): http://www.nwfusion.com/
news/1999/0319network.html.
Many of the industrys leading test labs use Chariot to help

them simulate application load traffic, set periodic baselining
for trending purposes, stress test networking equipment and
more. Here are a few of the most recent industry tests where
Chariot has been used:
Network World: Test-drive your network designs. Chariot
was used in a test of four simulation tools. Chariot was used
to provide a benchmark for accuracy assessments against the
simulation products being tested. See (login may be required):
http://www.nwfusion.com/review/0524rev.html.
PC Week Labs: Software VPN IPSec-friendly.
Ganymedes Chariot 2.2 was used to evaluate F-Secure VPN+
4.0 from Data Fellows Inc. Chariot 2.2 was used to gauge the
performance hit caused by IPSec encryption and was able to
show a disconcerting 50 percent to 70 percent loss in throughput using the fastest algorithm. See: http://www.zdnet.com/
pcweek/stories/news/0,4153,394399,00.html.
Network World: Benchmarking Layer 3 switches: Fooling
the switches. Network World did a focus on high speed
LANs and used Chariot as part of this test. See (login may be
required: http://www.nwfusion.com/newsletters/lans/
0405lan1.html.
Network Computing: Foundrys FastIron II forges past
Midrange Layer 3 rivals. Network Computing invited
vendors to submit fixed-configuration Layer 3 products that
supported 10/100 Fast Ethernet interfaces, as well as OSPF
routing protocols. Chariot was used in this test. See http://
www.techweb.com/se/directlink.cgi?NWC19990308S0017.
Federal Computer Week: Expanding your view of the net.

This is an excellent article which highlights how the U.S.
Postal Service uses both Chariot and Pegasus to test and
monitor their network and applications. See: http://
www.fcw.com/pubs/fcw/1999/0531/fcw-techbrief-05-3199.html
Network World: Xeon packs server punch. Chariot was

used in this review of Xeons new ProLiant 6500 enterprise
server. Chariot was used to stress the network interface cards
(NIC). See (login may be required): http://
www.nwfusion.com/reviews/0405revcompaq.html.
Network Magazine: Application Performance Management

Software. Ganymede Software is one of several products
featured in an article about application performance management and why everyone agrees it is needed. See: http://www/
networkmagazine.com/magazine/archive/1999/05/
9905tech1.htm
InternetWeek: The Odyssey continues: How we tested.

InternetWeek set up a performance test designed to mirror
real-world traffic patterns obtained from the University of
Hawaiis IT staff. Ganymedes Chariot 2.2 was an intregal
part of this test. See: http://www.techweb.com/se/
directlink.cgi?INW19990510S0055.
Ganymede Software
Yes! Please add me to the Perfomance Monitor mailing list!

*First Name:
*Email Address:
Title:
*Company:
*Address:
Address:
http://www.ganymede.com/company/newsletter/subscribe.phtml (1 of 2) [3/14/2000 8:18:43 AM]
*Last Name:
Ganymede Software
*City:
*State:
Zip/Postal Code:
*Telephone Number:
Fax Number:
Submit Request
http://www.ganymede.com/company/newsletter/subscribe.phtml (2 of 2) [3/14/2000 8:18:43 AM]
Ganymede: The Industry Standard for Measuring Performance
The Industry Standard for Measuring Performance

Networks constantly grow and change. This makes planning and what-if
analysis critical to avoid disruptions. As you add applications or hardware, you
must predict how they will impact smoothly running applications. Ganymede
Software has developed a product to give you real-world evaluation of
performance, products, and technologies.
Chariot is the only application-layer network tester on the market. It began as a
product to allow IT managers and networking vendors to address their project
needs, and quickly became the chosen solution for all the major labs testing
networking hardware and software.
Today, Chariot is the industry standard for network performance testing in more
than 1000 businesses and test labs all over the world. Chariot helps determine
true end-to-end performance of complex, multi-protocol networks by testing like
no other tool can... from the application layer.
http://www.ganymede.com/products/chariot/index.phtml (1 of 3) [3/14/2000 8:18:58 AM]
Download Qcheck!
Ganymede Software's
network performance
Product Highlights
Chariot was designed to help you:
Ensure smooth rollout of a new application by predicting its impact on
your network
Make the right technology investments by viewing performance before
you purchase
Manage the evolution of your network by verifying additions and changes
Chariot provides IT professionals with a tool that is vital to the success of a
variety of IT projects, including:
Performance Troubleshooting
Voice Over IP Deployment
New Application Rollout
Network Products and Technologies Comparison
Multimedia Applications Implementation
Networking Product Development
Don't guess at the impact of a new application or network configuration... With

Chariot, your critical decisions are based on concrete, real-world data!
How it Works
Chariot measures response time and throughput of complex, multi-protocol
networks. Using Performance Endpoints, Chariot generates real network
traffic, allowing you to measure response time, throughput and connectivity...
before you deploy an application!
Chariot allows you to create controlled testing conditions that simulate your
own custom network environment. You can send the same types of traffic
generated by your unique mix of applications and protocols through network

products and technologies you're evaluating. You can actually test different
configuration scenarios...before you make a decision or a purchase!
Ganymede: How Does Chariot Work?
How Does Chariot Work?

First let's define two terms: Performance Endpoints and Application Scripts.
Performance Endpoints
A Performance Endpoint is a "skinny" software agent you install on
computers throughout your network. Endpoints can emulate thousands of
users, with multiple data types, protocols, and data rates. Multiple
endpoints give you the ability to test point-to-point, point-to-multipoint,
multipoint-to-multipoint, and even multicast connections (see below).
Application Scripts
Application Scripts emulate the flow of application network traffic. They
make the same calls to the network protocol stacks, and invoke the same
load on the stack, as production applications. This way you can test
application traffic on your network without the risk or expense of
deploying the actual application. Application scripts can be customized
for number of users, payload, and delays. Scripts can emulate anything
http://www.ganymede.com/products/chariot/howitworks.phtml (1 of 2) [3/14/2000 8:19:01 AM]
Ganymede: How Does Chariot Work?
Download Qcheck!
Ganymede Software's
network performance
from a simple file transfer or a complicated SAP R/3 transaction to a

streaming multi-media application.
Chariot uses Performance Endpoint technology to give you a competitive
edge-and peace of mind! The Chariot console tells an endpoint how to emulate a
particular application by sending it an Application Script and other test setup
information:
1. The script describes the type and amount of data to send/receive, when to
connect and disconnect, and what delays should be used to emulate
end-user or application overhead. The endpoint shares the script with its
partner, then runs the test.
2. At the end of the test, Endpoint 1 sends the test results back to the Chariot
console.
3. You can use the results immediately to evaluate network performance or
export the results to text, CSV, or HTML for later use.
Click here for a multimedia demo of Chariot!
http://www.ganymede.com/products/chariot/howitworks.phtml (2 of 2) [3/14/2000 8:19:01 AM]
Ganymede: Chariot Solutions
Chariot Solutions
Deploying Voice over IP
Comparing Networking Products and Technologies
Implementing Multimedia Applications
Deploying Voice over IP
While many network managers have been able to control IS budgets, most
companies have experienced explosive growth in their telecommunications
http://www.ganymede.com/products/chariot/solutions.phtml (1 of 12) [3/14/2000 8:19:09 AM]
Download Qcheck!
Ganymede Software's
network performance
costs. The question being asked is Can you save money by using your
under-utilized WAN links to run VoIP applications?" By sending voice traffic
through unused space on data networks, companies may be able to slash
communications costs by up to 40%.
This is great news, but IT organizations are already overworked, and adding
ownership of voice services may be more than most want to handle. Many IT
managers are not implementing VoIP because they aren't sure their existing
infrastructure can support the technology.
The ability to understand whether a network can handle VoIP and how it will
affect business critical application response time has been impossible to predict
without first deploying the actual application. By emulating the traffic generated
by VoIP applications, Chariot can give you an accurate estimate of how VoIP
traffic will affect your business critical traffic.
Chariot, the industry standard for measuring end-to-end network performance, is
an innovative software tool that measures response time and throughput of
complex, multiprotocol networks. Chariot software uses Performance Endpoint
technology to generate real network traffic. A Performance Endpoint is a
"skinny" software agent installed on computers throughout the network. The
endpoint uses protocol-independent Application Scripts to emulate any
application's traffic over your network. This technology allows you to measure
response time, throughput and connectivity in your network.
Use Chariot to:
Determine if your current network infrastructure can support VoIP.
Test the current network infrastructure with Chariot tests to determine
throughput and response time issues within your network. Use Ganymede
Software's Application Script that emulates VoIP traffic and run a Chariot
test to validate that your network has the proper delay characteristics to
support delay-sensitive traffic like voice.
Determine the impact on business-critical applications.
Use Chariot to baseline existing application performance measures, then
emulate new VoIP users. Easily determine how voice traffic will vary the
response time and throughput users are expecting. By varying the number
of voice channels tested with Chariot, you can determine the number of
concurrent calls you can process with your gateway without impacting
other performance.
Emulate varying payload and data rates.
Chariot scripts are easily tailorable with the click of a mouse. You can
vary the data rate of VoIP traffic, and the amount of traffic sent to ensure
that the network can handle various loads.
Implement and verify proper compression and traffic prioritization
schemes.
Ensure voice traffic receives proper prioritization in the network by
verifying prioritization schemes using Chariot to emulate VoIP
application traffic over your network. Chariot's consistent, repeatable tests
allow you to test various CODECs to see which one can give you the
combination of number of calls and the quality you need.

When a company introduces a new application into the network, making sure
that application performs properly is of paramount concern. But how can an IT
manager guarantee the application performs the way the users expect? How can
the IT group predict the impact on the network and other existing applications?
If a problem like slow response-time does arise, the resolution is a reactive
process. Finding problems after they occur is difficult, expensive and
time-consuming - not to mention embarrassing! Users are rarely tolerant of
slowdowns or failures when it impacts their productivity. Don't let an
application deployment fail because of poor planning on your part. Know ahead
of time what the performance will be and what the impact on other applications
will be. Set your users expectations with facts, not guesses. And, fix problems in
time.
With Chariot, you can proactively test application performance in terms of
response time and throughput before the application is deployed. If problems do
arise, you can separate network performance from application performance to
determine the root of the problem. Pinpoint trouble spots and resolve them
before users ever notice a problem.
Use Chariot to:
Ensure successful application rollouts
Before actually deploying a new application, emulate it on the network to
measure its actual performance and the impact on existing applications.
Ganymede Software's Application Scripts can emulate any application
before you actually deploy it. Run the script between the actual clients
and servers that will be running the application and see if there are any
network bottlenecks or if the new application will negatively impact other
applications. If you see a performance hit for other business-critical
applications, make the necessary infrastructure or application changes
before the deployment.
Emulate any application
Chariot ships with a library of Application Scripts designed to emulate
most of the major business applications on the market today as well as
scripts for new technologies such as video conferencing and Voice over
IP. In addition, Ganymede supplies a web site where users can share
scripts that they have created and have found useful. This same web site is
designed to make it easy for Ganymede to make new scripts available
between releases to better serve the customers. Each script is fully
tailorable with a point-and-click interface. You can change the rate at
which data is sent, the amount of data, and the type of data. Add "sleep
times" to simulate processing time to make tests even more realistic.
Verify changes
With Chariot, you run consistent, repeatable tests. The exact application
flows are repeated each time that you run a test, so you know that the
same load, between the same locations is repeated over and over. As you
make changes to the network to support a new application, you can repeat
the test using the same Application Scripts and the same Performance
Endpoints on the clients and servers and ensure that the changes you
made are the right ones to support the new application load.
Comparing Networking Products and Technologies

Networking's only constant is change. As a result, IT organizations must
frequently purchase new network products and technologies. Vendors realize the
need for reliable, high-performance networking products and technologies and
provide consumers with 10 times as many choices as just 5 years ago. How does
an IT manager choose between vendors, products, and technologies, or justify a
purchasing decision? They must begin and end with a real-world evaluation of
performance.
Whether it's a NIC, router, switch, packet-shaper, protocol stack or even a new
network infrastructure, every purchasing decision can affect your company's
bottom line. When it comes to real-world performance, the specifications in a
glossy product brochure don't necessarily reflect the performance you'll see in
your network. How can you be assured that your next networking purchase is a
smart one? Because corporate networks vary in their application and protocol
mix, it is very difficult to determine which vendor's product will best suit your
network.
Making an "apples-to-apples" comparison of vendors' products and technologies
with real-world application traffic is key to making informed purchasing
decisions. Ganymede Software's Chariot allows you to send the same types of
traffic generated by your unique mix of applications and protocols, through
networking products and technologies that are under evaluation. You now have
the ability to make informed purchase and deployment decisions based on
concrete, real-world data.

Use Chariot to:
Test using real application traffic
Test hardware using traffic that looks just like your network traffic.
Because Chariot allows you to mix applications and protocols within each
test, you can see exactly how the new products will perform with in your
production environment. Our customers have found that this reality check
has saved them money and improved their overall network performance.
See performance from an end user's perspective
Chariot measures response time, throughput, and transaction rate at the
application layer of the protocol stack, just as your users experience it.
This way of measuring allows you to establish baselines for your help
desk and get SLA information from an end-user perspective. Now you
can communicate expectations of performance to your users based on
information they can relate to - not simply in packets-per-second, or
router up-time.
Use reliable, repeatable tests for an "apples to apples" comparison
Set up a Chariot test to send a specific mix and quantity of traffic through
the device or software being tested. By using Chariot to reflect your
traffic patterns, you can see wide variations in performance - not the
"facts" that vendors quote in their marketing material. Repeat the test to
compare multiple vendors' products and determine which will perform
best in your environment.
Test capacity of new network products and software
Stress test network products and software to find breaking points before
investing.
Implementing Multimedia Applications

Multimedia applications are quickly finding their way into the corporate
network. Bleeding-edge testing has come and gone, and now corporations are
beginning to reap the rewards of deploying applications like videoconferencing,
Voice over IP (VoIP), and IP Multicast. Because of the huge amounts of data
that these applications send over a network, it is important that your corporate
network is ready for its deployment.
Videoconferencing, VoIP, and multicast are all proven technologies, but their
implementation can be an arduous and up to now unpredictable task. IT
Professionals must explore performance implications when contemplating a
multimedia deployment, and this has been all but impossible to accomplish
without first deploying the application. Chariot can emulate real-time,
multimedia streaming applications such as NetMeeting, RealAudio, RealMedia,
PointCast, and Voice over IP. Use Chariot to emulate complex streaming
applications and test how the new traffic will affect the performance of
applications on your network. This allows you to see the affect these
technologies and applications will have on your network - before you deploy.
Use Chariot to:
Determine the impact of multicast technology on your network with no
risk.
Chariot lets you create controlled testing conditions that simulate your
own network environment, so you can test without going live. Chariot
tests can help you decide where to locate multicast servers, ensure that
routers are configured correctly, determine send rates, and examine
whether data is getting lost. Test different configuration scenarios without
risk to your network, and before making costly technology investments.
Determine the effect of multimedia traffic on business-critical applications.
Use Chariot to emulate business-critical applications and multimedia
traffic over the network to determine performance degradation. Run a test
using Application Scripts of your main-line applications, and then run the
same traffic flows adding multimedia traffic and see what the difference
is. Don't guess at the impact. Use Chariot to get detailed reports with data
that concretely shows the difference.
See where there is a problem, solve it, and verify your solution.
Chariot helps you pinpoint problem areas when testing and deploying
multimedia applications. As you make changes to the network to support
multimedia, you can repeat the test using the same Application Scripts
and the same Performance Endpoints on the clients and servers and
ensure that the changes you made are the right ones to support the new
application load.

Whether developing networking products, it is important to keep the customer in
mind. How will the customer use the product? How will the product interoperate
with other networking products? These questions must be considered throughout
the life cycle of a product development. During test, they must evaluate their
product's capabilities and performance in customer-specific environments.
When marketing the product, vendors must demonstrate consistent, reliable
product performance. When servicing the product, they must be able to recreate
problems found in customer networks.
Vendors rarely have the luxury or budget to fully replicate customer
environments, but must test over environments including multiple protocols,
operating systems, application types, and topologies. They need to be able to use
the same tests for thorough test and regression analysis. Chariot lets vendors
quickly, easily, and cost-effectively test their networking products the same way
customers and test labs will. Chariot can emulate many types of applications,
including complex ERP and multimedia applications. Chariot's Application
Scripts interact directly with the network protocol stack and run on 15 different
operating systems, enabling vendors to truly replicate a heterogeneous network.
Using Chariot, vendors can test their networking products in a variety of
customer environments.
Use Chariot to:
Test using real application loads
Chariot generates real application network traffic using the same APIs as
standard applications. In this way you can test your product with the
operating systems and protocol stacks your users will be using. Chariot
can run large tests emulating hundreds of users to stress your products.
With a Chariot test, you can introduce variables in the types of and size of
the data you are sending across the network to see how your product will
react to different situations, and you can repeat the same tests as you
make changes during development. Unlike other testing products, the data
flow in Chariot tests is bi-direcitonal, so you can see real applications in
realistic settings.
Ensure that your product can support leading-edge technologies
Verify that your network device recognizes and handles multimedia
traffic and streaming applications. Only Chariot can test QoS and
prioritization techniques of a networking product. Because Chariot sees
through the network, running from the client to the server, you can use it
to test not only your product, but how your product interoperates with
others in a larger networking environment.
Improve your productivity with one testing solution
With Chariot technology, you can test any topology, create repeatable
tests, and automate regression testing. Chariot's interface is simple to
master, and you won't need a fleet of application experts to run tests.
Tests can be started through a GUI or you can use the command-line
interface to automate your testing. Use only a few workstations to
generate huge tests. With Ganymede's unique and patented Performance
Endpoint technology a single pair of computers, you can emulate
hundreds of users, saving time and money in setup, space, and education.
Additionally, because the endpoints run on all the major platforms, you
can test with any environment your users will have.
Market your product effectively
Available since 1995 as an application-level testing solution, Chariot
quickly became the standard for network performance testing by all the
major test labs. Before you subject your new product to reviews by the
major lab, run tests with Chariot to see what they will see. Either you can
run benchmarks against your competition, or others will, and you can do
this with Chariot's consistent, repeatable tests to ensure a fair comparison.
With Chariot, you get meaningful test results expressed in metrics that
your users will understand - application response time and througput.
When the Help Desk gets a call from a user saying that his response time for
Lotus Notes e-mail is slow and getting slower, what happens? In many
enterprises, the call goes out to the network technicians that there is a problem
with response time from Dallas to New York. You know that it is an e-mail
problem, but where and why?
When a problem like slow response time does arise, the resolution is a reactive
time-consuming. Users are rarely tolerant of slowdowns or failures when it

impacts their productivity. How can you quickly identify whether the problem is
in the application or the network? How can you isolate where in the network the
problem is? How can you be sure that you have fixed the problem, and the users
won't continue to complain?
Use Chariot to:
Recreate the problem
When a problem is reported, run a Chariot test, emulating the application
in question from the user's desktop to the server. The results of the test
will show you the network response time and throughput for that
application. You can immediately see if the network is the problem. And,
you can do it without having to get the user who is complaining (and
already unhappy) involved with the diagnosis!
Isolate the problem
Once you have determined that the network is the problem, run the
Chariot test first between the client and server, then repeat the test from
the desktop to other points in the network until you determine on which
segment the problem is. Because Chariot emulates the
application, you do not need to have the application itself deployed in
multiple places to test its network impact. Chariot saves both time and
money because all of this can be done from your desktop - without
putting someone on a plane or calling in support in the remote sites. If
you need to use an analyzer to diagnose problems, Chariot can recreate a
controlled application flow. This way you can complete your analysis
without involving the users.
Verify changes
With Chariot, you get consistent, repeatable measurements. The exact
application flows are repeated each time that you run a test, so you know
that the same load, between the same locations is repeated over and over.
As you make changes to the network to fix the performance problem, you
can repeat the test using the same Application Scripts and the same
Performance Endpoints on the clients and servers and ensure that the
changes you made are the right ones to eliminate the problem. With
Chariot you will know with confidence that the problem is fixed when
you say it is.
Ganymede: Chariot can give you peace of mind!
Chariot can give you peace of mind!

With Chariot you can:
evaluate the performance and capacity of network products
stress test network devices
troubleshoot network performance problems
measure the performance impact of network changes
measure the true end-to-end response time and throughput of complex,
multiprotocol networks quickly and easily
separate network performance from application performance in your
network
understand impact of application loads on network performance
OK, convince me!
http://www.ganymede.com/products/chariot/summary.phtml (1 of 2) [3/14/2000 8:19:12 AM]
Ganymede: Chariot can give you peace of mind!
Download Qcheck!
Ganymede Software's
network performance
Chariot lets you to test networks at the application level using real-world traffic,
emulating applications like e-mail, database updates, voice over IP, and the
Web. Unlike packet generators, which produce a steady stream of unchanging
data, Chariot tests generate traffic that is bi-directional and variable. Chariot
tests run over multiple protocols and interact directly with the protocol stack,
measuring performance degradation caused by lost frames, timeouts, and
congestion control mechanisms.
Chariot real-world
Generates real-world, repeatable, application network traffic that can
results be measured from the end-user's perspective (e.g., response time,
throughput, jitter)
Measure the performance of complex networks, consisting of multiple
protocols, multiple operating systems, multiple network topologies, and
multiple application types (see back panel for details)
Predicts the impact of planned network changes, such as new
applications, additional users, new hardware, and new technologies such
as IP Multicast, multimedia, and QoS
Chariot flexibility
Installs and is ready to use in minutes and ease of use
Simplifies and automates regression testing
Isolates network performance from application overhead to enable easier
troubleshooting of network problems
http://www.ganymede.com/products/chariot/summary.phtml (2 of 2) [3/14/2000 8:19:12 AM]
Ganymede: Chariot Technical Specifications
Chariot Technical Specifications

WINDOWS NT CONSOLE REQUIREMENTS
Hardware & Operating System
Microsoft Windows NT for x86 v4.0
Pentium or equivalent system with at least 32MB of memory
Protocols
TCP/IP
TCP/IP WinSock2 stack included with Windows NT
(NT Service Pack 3 or higher recommended)
SNA
Microsoft SNA Server stack>
(v4.0 recommended)
IBM Communications Server for Windows NT v5.0
http://www.ganymede.com/products/chariot/techspecs.phtml (1 of 3) [3/14/2000 8:19:16 AM]
Download Qcheck!
Ganymede Software's
network performance
IBM Personal Communications for Windows NT

(v4.11 or higher)
IPX/SPX
IPX/SPX stack included with Windows NT
WINDOWS 95/98 CONSOLE REQUIREMENTS

Microsoft Windows 95 or Windows 98
Protocols
TCP/IP
TCP/IP WinSock2 stack included with Windows 98
(available separately with Windows 95)
SNA
IBM Personal Communications for Windows 95/98
(v4.11 or higher)
IPX/SPX
IPX/SPX stack included with Windows 95/98
AVAILABLE CONFIGURATIONS
Windows NT 10,50,200, and 500 concurrent connections.
Windows 95/98 10 or 50 concurrent connections.
OPERATING SYSTEMS SUPPORTED

Windows 3.1, 95, 98, NT x86, and NT Alpha
Novell NetWare
IBM AIX, OS/2, and MVS
Compaq True64 Unix
HP-UX
Linux x86 and MIPS
SGI IRIX
SCO UnixWare
Sun Solaris Sparc and x86
Ganymede: Test Labs Using Chariot
Test Labs Using Chariot

The Tolly Group - FRAD test
The Tolly Group - Madge Networks Smart 16/4 PCI Ringnode Mk3
(Wake-on-LAN) & Presto PCI Plus Token-Ring Adapter Application T
The Tolly Group - Olicom Evaluation of High-Speed Token-Ring vs. Fast
Ethernet Switch
The Tolly Group - Packeteer, Inc., PacketShaper Traffic Shaping
Capabilities Evaluation
Information Week - "Smooth Operations Depend on Smart Testing Plans"
Network World - King of the NOS Hill
PC Magazine - VPNs - How We Tested
http://www.ganymede.com/products/chariot/testlabs.phtml (1 of 7) [3/14/2000 8:19:21 AM]
Download Qcheck!
Ganymede Software's
network performance

Information Week - QoS Device test
InternetWeek - Firewall test
Network Computing - Intrusion Detection Review
Network Computing - VPN Review
Computer Reseller News - CMPmetrics NIC test
Computer Reseller News - CMPmetrics NIC test
Network Computing - ISDN test
InternetWeek - ATM Switch test
Network Computing - IPSec VPNs: Take Us To the Pilot
Network Computing - Wireless T1 WANs Make Waves
VARBusiness - How We Tested Layer 3 Switches
3Com Leads USB-to-Ethernet Race
Network Computing - Cisco 800 Series Sets New ISDN Standard
Network Computing - Intrusion Detection Review

VARBusiness - How We Tested 10/100 Ethernet Hubs
InternetWeek - Gigabit Ethernet Switch test
VARBusiness - How We Tested Remote Access Servers
Windows Magazine - USB Ethernet Device Excels
Network Computing - Cisco: More Ports for Network Storms
Network World - Xeon Packs Server Punch (Compaq ProLiant 6500 Server
Test)
The Tolly Group - 3Com OfficeConnect LAN Modem ISDN Router
Competitive Evaluation
Windows Magazine - Low-Cost USB Networking
Network Computing - Wired on Wireless: A New Clss of 802.11 Devices Go
the Distance
PCWeek - Software VPN IPSec-friendly
Network Computing - Foundry's FastIron II Forges Past Midrange Layer 3
Rivals
PC Magazine "Being There" (round-up of remote-access servers)

Sm@rtReseller "QoSMaster - Limited Use Highway" (review of IP
Highway Inc's QoSMaster - bandwidth mgr)
The Tolly Group - Olicom, Inc. RapidFire 3140 TR 16/4 PCI Adapter
Competitive Evaluation
Information Week "A Delicate Balance" (evaluation of load-balancing
switches and routers)
PC Week Labs - Back to drawing board for Designer 2.0 (Network
design/diagramming tool test)
PC Week Labs - IP overseer overlooks breakthroughs (Bandwidth
Optimizer test)
Network Week "Enterprise--Gigabit Ethernet" (test of QoS on Gigabit
Ethernet Switches)
InternetWeek - Gigabit Ethernet Races Along (Gigabit ethernet switch test)
PC Magazine VPN test
InternetWeek - ATM Switches: More Features -- But Are They Better?
(ATM Switch test)
InternetWeek - Thin is in But Does It Win? (Windows NT workgroup
server test)
PCWeek Labs - NIC knack: Pro/1000 is fast and inexpensive (Gigabit
ethernet NIC test)
Data Communications - FRADs: Halfway There (FRAD test)
PC Week Labs - Universal bandwidth control (Bandwidth manager test)
PC Week Labs - Router gets handle on high bandwidth (T-3 router test)
Network Computing's NIC Array test
PC Week Labs - Loran hits the spot with KinNetics (Web-based network
management and trend analysis tool test)
Network Magazine - Gigabit Ethernet to the Server (Gigabit ethernet test)
Internet Computing - Bandwidth Manager test
Network Computing's Frame Relay Management Device test
VARBusiness - Layer 3 switch test
PC Week Labs - TrafficWare 2.1 controls IP traffic based on user accounts
and groups (Bandwidth management tool test)
InternetWeek - The Fastest Networks On Earth (Gigabit ethernet products
test)
Network Computing's SOHO ISDN router test
InternetWeek - Three New NICs Ease Speed (100Base-T NIC test)
InternetWeek - 100Mb Ethernet NIC test
Network Computing's Push Technology Middleware test
Network Computing's Segmentable workgroup hub test
Network Computing's Fast Ethernet Switch test
Network Computing's Voice and Data FRAD test
The Tolly Group - ATM Interoperability: PNNI Testing for the Network
Interoperability Alliance
Computer Retail Week "10/100 Network Interface Cards" (review of NICs)
InternetWeek - Gigabit Ethernet Switch test
Network Computing's Gigabit Ethernet Switch test
Network Computing's ATM NIC test
InternetWeek - ATM Switch test

Network Computing's ADSL preview
Data Communications - Branch-Office Router and FRAD test
Network Computing's FRAD test
Ganymede: Try Chariot for Free!
Try Chariot for Free!

Over the past 4 years, Chariot has become the industry standard for testing
networks and networking equipment. Now you can evaluate Chariot on your
network for Free!
Click here to download a FREE 3 day evaluation copy of Chariot. And coming
soon, you can check out the latest industry benchmarks based on Chariot by
visiting the CMPmetrics website.
Now with enhanced multimedia support, Chariot is the only network testing
system to test the end-to-end network performance of almost any networked
application. Chariot emulates real-world application traffic, running scripts
which mimic a variety of applications, including VOIP, videoconferencing,
Web, ERP, and others.
Click here for a multimedia demo of Chariot!
http://www.ganymede.com/products/chariot/evaluation.phtml (1 of 2) [3/14/2000 8:19:24 AM]
Ganymede: Try Chariot for Free!
Download Qcheck!
Ganymede Software's
network performance
http://www.ganymede.com/products/chariot/evaluation.phtml (2 of 2) [3/14/2000 8:19:24 AM]
Ganymede: Monitoring and Troubleshooting Application Performance
Monitoring and Troubleshooting Application Performance

Pegasus is the only product that allows IT managers to see application
performance from the top down... from the user's perspective. Pegasus shows
you the total response time a user is experiencing and then breaks that response
time down into client, network, and server components.
Occasional performance problems are inevitable. But now, Pegasus will identify
the source of a problem, and help you prioritize which problems to tackle first.
Pegasus provides you with faster problem resolution and allows you to isolate
and resolve problems with fewer people and less specialized skills.
http://www.ganymede.com/products/pegasus/index.phtml (1 of 2) [3/14/2000 8:19:29 AM]
Ganymede: Monitoring and Troubleshooting Application Performance
Product Highlights
Download Qcheck!
Ganymede Software's
network performance
Once your systems and applications are in place, you can practically guarantee
reliable, predictable application performance to your users! With Pegasus, you
can quickly and easily:
Monitor end-user performance
Detect, prioritize, and isolate performance problems, before users
experience them
Benchmark and monitor Service Level Agreements (SLAs)
Analyze history
Track performance trends, and feed them back into the planning process
Minimize troubleshooting time.
How it Works
Pegasus Application Monitor passively monitors the performance of application
transactions at the desktop, as they occur, breaking out response time by client,
network, and server.
Pegasus Network Monitor actively emulates known application transaction
flows to measure repeatably how well the network is handling application
traffic, giving you consistent, "apples-to-apples" comparison of network
performance over time.
Pegasus provides IT Professionals with a system for:
Managing Service Level Agreements (SLAs)
Addressing Policy-based management and QoS
Monitoring application response time
Troubleshooting performance problems.
http://www.ganymede.com/products/pegasus/index.phtml (2 of 2) [3/14/2000 8:19:29 AM]
Ganymede: How Does Pegasus Work?
How Does Pegasus Work?

1. The ranking of problems by severity in Pegasus lets firing-line staff
quickly identify which applications, network paths, and servers have
the worst performance.
2. Click on Severity to prioritize application performance problems and
highlight a critical problem with Lotus Notes.
http://www.ganymede.com/products/pegasus/howitworks.phtml (1 of 4) [3/14/2000 8:19:53 AM]
Download Qcheck!
Ganymede Software's
network performance
3. Click on the Lotus Notes severity icon to show that response-time

exceptions are increasingly dramatically.
4. Click on the Response Time hot link to display a breakdown of client,

network, and server response time, highlighting an increase in
network response time.
5. Further drill down on Traceroute Analysis shows you which element

in the path has increased latency when compared with the baseline of
normal routes, identifying a potential trouble spot.
Ganymede: Pegasus Solutions
Pegasus Solutions
Managing Service Level Agreements
Application Response Time Monitoring
Policy-Based Management and Quality of Service
Managing Service Level Agreements
A Service Level Agreement (SLA) is a contract between a service provider and
http://www.ganymede.com/products/pegasus/solutions.phtml (1 of 9) [3/14/2000 8:19:59 AM]
Download Qcheck!
Ganymede Software's
network performance
its customers. The ultimate goal of the SLA is to deliver a predetermined level
of availability and performance from the IT infrastructure. Corporate America
has been slow to adopt SLAs because they are the difficult to establish and then
difficult to monitor. As an IT manager, you must set an appropriate goal for the
SLA, and set it in a way that is measurable and meaningful to your customers.
End users don't want to know about router uptime. They want to know about the
response time for their critical business applications.
An IT manager can use an SLA to set realistic expectations for the level of
network performance a user can expect to see. What's more, the IT manager can
use an SLA to negotiate for more resources to upgrade the network if end users
find their current options unacceptable. An SLA is an objective tool that can
help IT departments communicate the benefits vs. cost tradeoff and can help
companies determine whether a particular network upgrade is worth the
investment.
Ganymede Software's Pegasus allows you to craft SLAs in terms that users can
relate to: response time, throughput, and connectivity. Pegasus is the only
product that provides continuous monitoring and SLA management for
end-to-end network response time, throughput and connectivity. It provides
network managers with the ability to run tests on a scheduled basis, track
performance history and trends, notify management about performance
problems, and track Service Level Agreements. Pegasus runs tests between
Performance Endpoints, which are special agents that run on machines in your
network. These endpoints emulate the flows of applications across the corporate
network, and then send performance data such as response time, throughput and
connectivity to the Pegasus server.
Use Pegasus to:
Establish the right SLAs.
By actively monitoring critical network connections throughout an
enterprise network, Pegasus is able to provide network administrators
with response-time and throughput information from an end-to-end
perspective. With a single Pegasus report, you can determine what
measures should be associated with SLAs that you are signing up for.
Pegasus helps you set user expectations and makes you comfortable that
you can meet them.

Monitor SLAs.
Like gazing into the crystal ball, Pegasus allows you to know that
performance is degrading before users do. By actively monitoring
connections over time, it is easy to determine which applications or
connections are potential problems. A single Pegasus report shows you all
the details you need to make an informed decision. With performance
trends and statistics from Pegasus, you can have business justification for
upgrades or enhancements to your network.
Automatically generate reports.
How many reports from devices all over your enterprise does it take to
prove you are providing the proper service levels to your end users? With
Pegasus, the answer is ONE. Automatically generated reports will give
you SLA reports broken down in the terms you need to prove you're
meeting your commitments. And with Pegasus' Web-based reports, your
users can see how well you are doing!
Application Response Time Monitoring

Predictable application performance is what guarantees customer service and
ensures that your corporation stays competitive. The job of IT is to help users be
increasingly productive. In this way, they can have a dramatic impact on
customer service, corporate competitiveness, and even the bottom line. End
users don't care about server uptime or the efficiency of network design; they
care about getting their jobs done. IT departments are responsible for making
technology help-not hinder-their productivity . Your success is based on the
critical application response time you deliver to your users.
To deliver predictable, reliable application response time you must be able to
monitor the performance of the applications on your network. This requires
tools that can provide end-to-end measurements for multiple types of
applications, systems, and networking protocols. Ganymede Software's Pegasus
is the only product that provides continuous end-to-end application monitoring
for enterprise networks like yours. Pegasus supports applications running on 15

operating systems (from Windows 3.1 to MVS) and works over the five most
popular networking protocols-TCP/IP, UDP, SNA, SPX, and IPX. Ganymede's
universal application support means that Pegasus can monitor any application
that runs on your network.
Pegasus is the only product that provides continuous monitoring and SLA
management for end-to-end network response time, throughput and
connectivity. It provides network managers with the ability to run tests on a
scheduled basis, track performance history and trends, notify management about
performance problems, and track Service Level Agreements. Pegasus runs tests
between Performance Endpoints, which are special agents that run on machines
in your network. These endpoints emulate the flows of applications across the
corporate network, and then send performance data such as response time,
throughput and connectivity to the Pegasus server.
Use Pegasus to:
Monitor end-to-end application performance
Choose the applications you want to monitor for individual users,
departments, or sites. Then select the schedule on which you want to
monitor them. You can choose one application or hundreds; one location
or thousands. Pegasus uses Ganymede Software's Application Scripts that
emulate any critical application on your network and runs these scripts
between Performance Endpoints. The endpoints are the clients and servers
on which your critical applications are running, so you can see the actual
network response time for applications and be alerted to slowdowns
before your users notice them.
Set thresholds for application response time
Pegasus lets you define response-time thresholds by application and
location and them monitors to assure that users are receiving the right
levels of service. When thresholds are crossed, the Pegasus Server can
send an alert to an alert manager to notify you that there is performance
degradation. Pegasus is also capable of monitoring response time and
automatically calculating thresholds. Similarly, when these
system-generated thresholds are crossed, you will be notified. This
automated threshold calculation can save you time as you are setting up
your application monitoring, and give you assurance that applications are
being properly monitored.
Feed back into the planning process
As you are monitoring response time, Pegasus can show you the trends
for performance to help you in planning for network upgrades and
changes. The detailed performance information that Pegasus provides
give you concrete performance statistics on which to base purchase
decisions. No longer will you have to guess when changes are necessary
or what the impact of those changes will be.
Policy-Based Management and Quality of Service

As an IT manager, you need to ensure that users of business-critical applications
are getting consistently good performance from those applications. There is a
new set of solutions, known collectively as policy-based management, available
to help ensure the right levels of service for each of your users with their
particular sets of applications. They let you establish rules, or policies, for how
different applications and users receive services from the network. A policy
server reads the policies from the repository and sends configuration directions
to the various network devices to implement Quality of Service (QoS).
However, the policy-based servers that configure equipment to implement rules
can't guarantee that policies will produce the desired results. How can you
ensure that policies are effective, and that end-users are getting the service they
demand?
The industry has made strides to define ways of implementing QoS, customers
today have a wide choice of implementations. With the variety of campus and
wide-area networking schemes in place today, an application may be using more
than one implementation of QoS in going from a client to a server. How can you
be sure that what you allocate as "high priority" or "delay-sensitive" traffic will
be processed consistently from end-to end?
Before setting policies, IT managers need to ensure that planned policies will
have the desired impact on application performance. Ganymede's Chariot fills

this need by testing the end-to-end response time and throughput of networked
applications and exercising the QoS implementations. After policies are set, IT
managers need to monitor the network continually to ensure that application
performance remains acceptable, even after changes are made to the network
(such as adding new users or new applications). Ganymede's Pegasus
performance monitoring software enables IT managers to ensure that policies
continue to work as expected over time.
Use Chariot to:
Evaluate QoS mechanisms
Which implementation of QoS is best for your network? Will it work
across your campus and WAN to deliver the desired performance levels?
Chariot can mix applications and protocols across both the local and wide
area networks and let you see the affect of different mechanisms. Chariot
can load vast amounts of application traffic that emulates your actual
network traffic (including video conferencing, ERP applications, Web,
and Voice over IP) so that you can now plan for, test and tune network
QoS. With Chariot, you run consistent, repeatable tests. In this way, you
are sure that you are comparing exactly the same application flows as you
test one scheme versus another.
Tune QoS
Chariot lets you experiment with different tuning parameters as you set
policies. What is the impact of high priority versus low priority? Will it
change with a heavily-loaded network? Chariot emulates the flows of
multiple applications and lets you see how QoS is working. You can
repeat the test, while changing network-tuning parameters and see exactly
what impact it will have. Increase the load on the network and see the
difference.
Verify changes
With Chariot, you run consistent, repeatable tests. The test results are
stored with the test setup, so you are never comparing apples and oranges
from one time to the next. As you make changes to the network to support
different policies or change QoS implementations, you can repeat the test
and ensure that the changes you made worked as expected.
Use Pegasus to:

Monitor network and application performance
Pegasus monitors the performance of the critical business applications
over time and allows you to ensure that the policies are being successfully
implemented. If there is a slowdown, Pegasus can isolate the client, the
network, and the server components of the application to help you find
and isolate performance problems when they occur.
Refine your policies
Pegasus monitoring data can help you see the trends of application
performance over time. When changes begin to appear, use this
information to help tune your policies to guarantee continued
performance.
When the Help Desk gets a call from a user saying that his response time for
Lotus Notes e-mail is slow and getting slower, what happens? In many
enterprises, the call goes out to the network technicians that there is a problem
with response time from Dallas to New York. You know that it is an e-mail
problem, but where and why?
When a problem like slow response time does arise, the resolution is a reactive
time-consuming. Users are rarely tolerant of slowdowns or failures when it
impacts their productivity. How can you quickly identify whether the problem is
in the application or the network? How can you isolate where in the network the
problem is? How can you be sure that you have fixed the problem, and the users
won't continue to complain?

Use Chariot to:
Recreate the problem
When a problem is reported, run a Chariot test, emulating the application
in question from the user's desktop to the server. The results of the test
will show you the network response time and throughput for that
application. You can immediately see if the network is the problem. And,
you can do it without having to get the user who is complaining (and
already unhappy) involved with the diagnosis!
Isolate the problem
Once you have determined that the network is the problem, run the
Chariot test first between the client and server, then repeat the test from
the desktop to other points in the network until you determine on which
segment the problem is. Because Chariot emulates the application, you do
not need to have the application itself deployed in multiple places to test
its network impact. Chariot saves both time and money because all of this
can be done from your desktop - without putting someone on a plane or
calling in support in the remote sites. If you need to use an analyzer to
diagnose problems, Chariot can recreate a controlled application flow.
This way you can complete your analysis without involving the users.
Verify changes
With Chariot, you get consistent, repeatable measurements. The exact
application flows are repeated each time that you run a test, so you know
that the same load, between the same locations is repeated over and over.
As you make changes to the network to fix the performance problem, you
can repeat the test using the same Application Scripts and the same
Performance Endpoints on the clients and servers and ensure that the
changes you made are the right ones to eliminate the problem. With
Chariot you will know with confidence that the problem is fixed when
you say it is.
Ganymede: Pegasus Summary of Features
Pegasus Summary of Features

Scalable - up to thousands of desktops.
Integrated Server - a single NT server, user interface, data repository, and
reporting structure for Application Monitor and Network Monitor.
Data Export - exports SNMP, ODBC, and automated CSV data.
Integration - integrates with HP Openview, CA Unicenter TNG, Concord
Network Health, DeskTalk Trend, MicroMuse NetCool, and a host of others.
AutoThreshold - continuously profiles application behavior and dynamically
sets thresholds as conditions change.
http://www.ganymede.com/products/pegasus/summary.phtml (1 of 3) [3/14/2000 8:20:02 AM]
Route Stability - baselines application path latency, path route history, and
automatically executes a Traceroute when an exception occurs.
Download Qcheck!
Ganymede Software's
network performance
Agent Portability - runs on multiple operating platforms and supports multiple

protocols.
Agent Automation - AutoDiscover finds all endpoints with IP addresses and
AutoInstall automatically updates endpoints when new versions become
available.
Ganymede Software is a leader in enterprise performance managment with its

Chariot and Pegasus products, numerous awards, over 900 installations, and
years of experience.
Monitors the performance of actual end user application transactions.

Breaks out transaction performance by its client, network, and server
components.
Monitors key system parameters - CPU utilization, memory paging, and disk
I/O.
Measures popular Internet and enterprise applications out-of-the-box and can be
customized to measure any TCP/IP application.
Supports Windows 95/98 and Windows NT endpoints with Application
Monitor.
Supports Windows 95/98, Windows NT, Sun Solaris, HP-UX, and IBM AIX
endpoints with System Monitor.
Scales to 2,000 endpoints per Pegasus server.
Monitors how well the network is handling application traffic by actively
emulating application traffic on a scheduled basis.
Emulates over 50 different applications out-of-the-box, and additional

applications using the optional Application Scanner.
Measures consistently, giving you an apples-to-apples comparison of application
performance across the network.
Runs on 16 operating platforms.
Supports TCP, UDP, SPX, IPX, and SNA.
Scales up to 5,000 endpoints per Pegasus server.
Ganymede: Pegasus Technical Specifications
Pegasus Technical Specifications

Pegasus Network Monitor System Requirements
Pegasus Server (minimum configuration)
Pentium 300MHz or higher, 128 MB RAM required, 256 MB RAM
recommended
Windows NT Workstation or Server 4.0 or higher
Pegasus Console
Netscape 4.0 or higher
Microsoft Internet Explorer 4.0 or higher
http://www.ganymede.com/products/pegasus/techspecs.phtml (1 of 3) [3/14/2000 8:20:05 AM]
Download Qcheck!
Ganymede Software's
network performance
Performance Endpoint Support

Operating platforms: Windows 3.1, Windows 95/98, Windows NT for
x86, Windows NT for Alpha, OS/2, NetWare, Solaris x86, SUN Solaris,
HP-UX, IBM AIX, Compaq Tru64 UNIX, SGI IRIX, SCO, UnixWare,
Linux x86, Linux MIPS, mainframe MVS
Protocols supported: TCP, UDP, IPX, SPX, APPC/SNA
Pegasus Application Monitor System Requirements
recommended
Pegasus Console
Integration
Pegasus complements and leverages existing network management systems:
Automated CSV, HTML, ODBC, SNMP MIB, SNMP traps
Manager of Managers: CA Unicenter, HP OpenView, etc.
Reporting Packages: Concord Network Health, DeskTalk Trend,
MicroMuse NetCool, etc.
Ganymede: Nervous About Enterprise Performance?
Nervous About Enterprise Performance?

Pegasus Network Monitor provides the information you need to detect, isolate,
prioritize, and diagnose network performance problems quickly. Pegasus Network
Monitor
Isolates the network portion of application flows to determine if the network is
causing an application to slow down.
Identifies performance bottlenecks using traceroute analysis.
Provides consistent apples-to-apples comparisons of application performance
across the network.
Provides a prioritized view of the severity of application performance problems
on your network.
http://www.ganymede.com/products/pegasus/netmonitor.phtml (1 of 4) [3/14/2000 8:20:09 AM]
Download Qcheck!
Ganymede Software's
network performance
Trends network performance over time so you can improve application

performance and end-user productivity.
Active Monitoring: What Is It?

The use of repeatable, end-to-end network performance measurements enables you the network manager - to establish baselines, discover meaningful anomalies, and
detect trends in a network. To accomplish this, Pegasus Network Monitor emulates
real-world application flows across a network on a scheduled basis to measure
response time, throughput, and connectivity. Using Performance Endpoint technology
and application scripts, Pegasus Network Monitor emulates an application at defined
intervals across the network.
Application Support: Is There a Script for my Application?
Pegasus Network Monitor shares the application script technology made popular by
Ganymede Software's industry-standard Chariot software. Currently over 100
application scripts are available for Pegasus Network Monitor, along with E-mail,
Web, and ERP applications. Application Scanner (sold separately) gives you the ability
to create IP-based application scripts, using a point-and-click interface.
Pegasus Reporting
To help you understand what is happening to application traffic on your network,
Pegasus reports include:
Monitor Console - Application Severity Index Summary, Composite Transaction
Time Report, and Trend Index Report.
Network Planning - Trend Index, Executive Summary, and Outlook Report.
Problem Detection / Troubleshooting - Severity Index, Priority One, Traceroute,
Best and Worst Connections, and Response Time Analysis.
Traceroute Analysis
Now you have the ability to identify which network hop(s) is causing performance
degradation! How? Pegasus executes traceroutes on a scheduled basis, establishing a
baseline history of the routes taken. When an exception occurs (threshold crossing), the
endpoint initiates a traceroute and sends the results to the Pegasus server. When an
exception occurs, Pegasus compares the route taken and the hop latencies of the
exception traceroute to the baseline traceroute. Unlike a standalone traceroute, the
Traceroute Report compares the established baseline latency to the latency of the route
taken when the exception occurred.
Pegasus Server: The Core of Pegasus
Pegasus server, common to both Pegasus Network Monitor and Pegasus Application
Monitor, is the core of Pegasus. Pegasus server resides on a dedicated Windows NT
computer and supports the common functions and the database for both Pegasus
monitors with a single integrated, Web-based Console. Pegasus server configures and
distributes monitoring schedules and configurations to the endpoints. Endpoints, in
turn, collect performance measurements and return that data to the server's database,
where reports are generated. Pegasus server can also be integrated with alert managers,
Manager-of-Managers, and reporting tools. Pegasus server can support 5,000 Pegasus
Network Monitor connections or 2,000 Application Monitor endpoints.
Performance Endpoint: Measures Performance
This technology, used by both Pegasus and Chariot, is a "skinny" agent which resides
on clients, servers, and mainframes throughout the IT infrastructure. The endpoint
actively emulates application flows and collects performance data for Pegasus Network
Monitor and Chariot, and monitors actual application transactions for Pegasus
Application Monitor. Pegasus auto-discovers endpoints with IP addresses, and
automatically upgrades future versions of the endpoint.
Companion Products
Application Scanner
Gives you the ability to create scripts for both commercial and
custom-developed IP applications that run on Windows 95/98/NT platforms
using a simple point-and-click interface.
Pegasus Application Monitor
Measures the performance of actual end-user transactions. It measures
application performance at the desktop, and breaks down this data into client,
network, and server performance data to give you a better understanding of the
causes of performance problems. By trending the performance of each
component over time (figure below), you can make changes to your clients,
servers, and network to improve application performance and end-user
productivity. Pegasus Application Monitor is particularly useful for managing
the end-user's actual experience.
Ganymede: What is causing your application performance problems?
What is causing your application performance problems?

Pegasus Application Monitor can help you find out the causes, select the best
course of treatment, and solve problems quickly. Application Monitor Measures
client transactions, breaking down performance by client, network, and server
components.
Identifies, prioritizes, isolates, and diagnoses application performance
problems quickly.
Manages the performance of mission-critical applications.
Ensures that service levels are delivered from the end-user's perspective.
Trends performance over time, so you can improve application
performance and end-user productivity.
http://www.ganymede.com/products/pegasus/appmonitor.phtml (1 of 4) [3/14/2000 8:20:14 AM]
Pegasus Console
Download Qcheck!
Ganymede Software's
network performance
The Pegasus Console is your portal into enterprise performance. It gives you a
prioritized view of the severity of application performance problems from the
user's perspective. It sifts through the mass of performance data, comparing,
analyzing, and prioritizing performance problems. The trend index tells you
how key applications are improving or degrading, so that you can forestall
problems before users even notice them.
Transaction Monitoring
Pegasus Application Monitor tracks and analyzes user transactions end-to-end,
measuring performance in terms of response time, throughput, and connectivity.
You need these performance measurements to establish baselines, discover
meaningful anomalies, and detect subtle trends in an application's behavior.
System Monitoring
Performance endpoints measure key system statistics so that performance
degradations can be associated with system performance within the same
application. System CPU, disk I/O, and memory paging are measured
continuously and sent to the Pegasus Server on a scheduled basis.
Traceroute Analysis
Pegasus executes traceroutes on a scheduled basis establishing a baseline history
of the routes taken by that connection. When an exception occurs (threshold
crossing), the endpoint initiates a traceroute and sends the results to the Pegasus
Server. Unlike a standalone traceroute, the Traceroute Report compares the
baseline latency to the latency of the route taken when the exception occurred.
By comparing the hop latencies of the exception traceroute to the baseline

traceroute, you now have the ability to identify which hop(s) is causing the
performance degradation.
Application Support
Application Monitor supports cc:Mail, POP3/SMTP e-mail, Lotus Notes,
Exchange, NT File/Print, Web, FTP, DNS, LDAP, Telnet, Pointcast, Oracle,
Sybase, MS-SQL, SAP R/3, PeopleSoft, Baan and any custom or off-the-shelf
TCP application defined by you.
Performance Endpoint
A technology shared by both Pegasus and Chariot, is a "skinny" agent that
resides on clients, servers, and mainframes throughout the IT infrastructure. The
endpoint actively emulates application flows and collects performance data for
Chariot and Pegasus Network Monitor, as well as monitoring actual application
transactions for Pegasus Application Monitor. Pegasus auto-discovers endpoints
with IP addresses, and automatically upgrades future versions of endpoint.
Pegasus Server
Common to both Pegasus Network Monitor and Pegasus Application Monitor,
is the core of Pegasus. The Pegasus server resides on a dedicated Windows NT
computer and supports the common functions and the database for both Pegasus
monitors with a single integrated Web- based console. Pegasus server configures
and distributes monitoring schedules and configurations to the endpoints.
Endpoints, in turn, collect performance measurements and return that data to the
server's database, where reports are generated. The Pegasus server can also be
integrated with alert managers, Manager-of-Managers, and reporting tools.
Pegasus server can support 5,000 Pegasus Network Monitor connections or
2,000 Application Monitor endpoints.
Companion Product
Pegasus Network Monitor

Provides the information you need to separate network performance from
application performance. Using application scripts, it detects and isolates
failures and performance problems in the network, and trends what is
happening to application traffic on your network.
Ganymede: Pegasus Development Partners
Pegasus Development Partners
DeskTalk Systems is a leading developer and supplier of network

management solutions. DeskTalk's TREND products provide network
managers with highly-automated, end-to-end performance management
software for heterogeneous enterprise environments.
http://www.ganymede.com/products/pegasus/devpartners.phtml (1 of 2) [3/14/2000 8:20:22 AM]
Ganymede: Pegasus Development Partners
Download Qcheck!
Ganymede Software's
network performance
Since 1994, Micromuse has developed Netcool, a suite of service-level

management applications for telcos, ISPs, and large-scale, mission-critical
enterprises. The core Netcool/OMNIbus application collects event
messages from diverse management platforms throughout the enterprise
and associates them with services for operators who are responsible for
monitoring levels of service availability. A service might be an
end-to-end application, a digital carrier service, a business unit, a virtual
private network, or an Internet connection.
Concord Communications, Inc., is the leading developer of Web-based

network reporting and analysis solutions that provide customers with the
information they need to measure the effectiveness of their IT investment.
The premier service providers, ISPs and Fortune 1000 companies turn to
Concord every morning for the network reports that enable them to make
faster, more educated business decisions.
http://www.ganymede.com/products/pegasus/devpartners.phtml (2 of 2) [3/14/2000 8:20:22 AM]
Ganymede: The Performance Endpoint... A workhorse you can count on!
The Performance Endpoint... A workhorse you can count on!

Performance Endpoints are unique in their ability to support all of Ganymede's
products (Chariot, PegasusTM, and Qcheck). Unlike other agents that have a
single function, Performance Endpoints (Endpoints) are multifunctional. They
are workhorses that other Ganymede applications can harness to carry out
specific jobs. For example, they can be used to:
Test the load of a new application on the network.
Monitor the performance of application traffic across the network.
Measure the performance of actual transactions on a client.
Measure key system statistics.
Measure the output of both active and passive technologies (see
Measuring What Matters white paper for discussion of active vs. passive
technologies).
Performance Endpoints-Versatile, Lightweight, Manageable, and Robust
Versatile - Performance Endpoints provide total network visibility. Endpoints
are available for 16 operating systems-from Windows to MVS-and run on six
http://www.ganymede.com/products/endpoints/index.phtml (1 of 4) [3/14/2000 8:20:32 AM]
Download Qcheck!
Ganymede Software's
network performance
protocols. Endpoints will

Run on the equipment you already have in your network. You don't have
to put in specialized network probes or buy special hardware. Endpoints
can run on a dedicated computer or on any computer "in the background".
They are always ready to execute a test.
Interact with each other over your network, regardless of the platform or
operating system on which they reside.
Help pinpoint the source of performance problems. You can tell whether
performance problems are network problems or application problems.
Figure 1. A Single Performance Endpoint Supports Chariot, Pegasus Network

Monitor, Pegasus Application Monitor, and Qcheck. An Endpoint can measure:
what happens when a new application is added to a network (load testing), the
performance of application traffic across the network (network monitoring), the
performance of production transactions on a client (application monitoring), and
the monitoring of key systems statistics (system monitoring).
Lightweight - Every Endpoint has been engineered to use the absolute minimum
of computational resources to accomplish its job. In fact, the resource impact of
Endpoints is often impossible for users to detect.
Endpoints are also lightweight in what they send across the network. The
flows between Ganymede servers/consoles and Endpoints use minimal
bandwidth and no polling is necessary.
Endpoints can return data on a scheduled basis, but will transmit
immediately in response to exceptions-also piggybacking any queued data
at the same time. Since the overhead of opening a network session is

highest for small amounts of data transfer, this piggybacking tactic is
another important way to conserve network bandwidth.
Users are not aware that the Endpoint code is running on the desktop.
Endpoints are always in sleep mode when not conducting a test with
Chariot, Pegasus, or Qcheck.
Endpoints are amazingly lightweight in cost-they are free! Upgrades are
free, and the latest Endpoint code is always available at the Ganymede
Web site.
(The Ganymede product documentation provides detailed data about memory

and disk space usage.)
Manageable - Deploying large numbers of Endpoints could have been

challenging. However, Ganymede has devoted significant resources to ensure
that the job of deploying and managing Endpoints is simple. You can do this a
number of ways:
Distribute Endpoints using any of the most common automated software
distribution schemes, including Microsoft SMS and Tivoli Software
Distribution.
Starting with Pegasus 2.1 and Endpoint 3.4, Endpoints can update
themselves automatically on a desired schedule. In this scenario,
Endpoints check a designated Intranet site for the latest version. If a new
version is found, the Endpoints automatically update themselves and
continue running exactly as before!
Since Endpoints are free, many organizations distribute them as part of
the standard server or desktop build ("golden master"). In this way, there
is no additional operation required to deploy an Endpoint wherever it
might be needed.
The Pegasus Server (v2.1 and beyond) can AutoDiscover installed
Endpoints anywhere in the IP address range you specify.
Endpoints support push-and-pull installation technologies including silent
install, SMS support, and one-click download-and-install of Endpoint

agents from the server.
Robust - Ganymede Endpoints
Are currently supported on 16 different operating systems from MVS to
Windows, and run on 6 protocols.
Have been optimized and perfected over many programmer-years. Many
thousands of endpoints are currently in use.
Represent one of the most heavily optimized and mature product
technologies in the application performance management marketplace
today.
Are shipped with Red Hat Linux and Cobalt RaQ2.
Ganymede: Performance Endpoints and Chariot
Performance Endpoints and Chariot

How does Chariot use Endpoints?
From the Chariot console, you design and run multiprotocol, multi-system tests.
When you tell Chariot to run a test, it distributes instructions to the Performance
Endpoints (Endpoints). These "skinny" agents emulate and drive traffic through
the network exactly like a real application, but without any application
overhead. Endpoints gather performance information about the traffic they
generate and return that information to the Chariot console.
1. Chariot instructs an Endpoint how to emulate a particular application.
2. The receiving Endpoint (Endpoint 1) keeps its half of the test setup and
sends the other half to its partner (Endpoint 2). The Endpoints then follow
the instructions and execute the test.
3. At the end of the test, Endpoint 1 sends the test results back to the Chariot
console .You can then use that data to determine the performance of the
network.
http://www.ganymede.com/products/endpoints/andchariot.phtml (1 of 3) [3/14/2000 8:20:38 AM]
Download Qcheck!
Ganymede Software's
network performance
Figure 2. The Endpoints and test instructions combine to form the core of
Ganymede Software's products. Using this active technology, Chariot can create
and measure almost any mix of traffic, anywhere in a network.
Chariot can provide a wide range of test possibilities from simple point-to-point
connections to complex client/server tests involving up to 500 connections at
once, emulating thousands of users.
Starting with Chariot 2.2, you can measure the network impact of deploying
newly emerging multimedia applications like IP Multicast. Chariot uses
Endpoints to measure the performance of the multicast traffic and measure its
impact on other business applications.
Chariot can also emulate a one-to-many application like Pointcast. In this
scenario, a single Endpoint can send the same data to multiple Endpoints
simultaneously. Chariot can use a many-to-many scenario to emulate how the
traffic from a distributed application affects network performance. This scenario
measures, for example, the response time of an E-mail application that is
distributed over several different locations or servers.
How does Chariot use Application Scripts?

Application scripts are sets of test instructions which consist of commands, such
as SEND and RECEIVE, as well as script variables, such as the size of the
buffer and the type of data in each SEND.
Application scripts are key to how we measure network performance in Chariot.
Application scripts model the real applications you use between computers in a
network. They make the same API calls to the network protocol stacks that real
applications make, causing the protocol stacks to perform the same work
involved in sending and receiving data.
Application scripts are generally independent of the network protocol. This
means the same script can be used with any network protocol supported by the
Endpoints you're using. (A subset of the scripts, called streaming scripts,
requires a datagram protocol, such as IPX, RTP, or UDP.)
Application scripts are stored at the Chariot console and are only delivered to
the Endpoints when you start a test.
Because of Chariot's flexibility it can emulate the flow of almost any application
in your network. Application script parameters can be modified easily by the
user, allowing scripts to be tailored to unique application models.
A large library of Application Scripts is shipped with Chariot and over 100 are
available free from Ganymede's on-line Application Script Library. Another
product, Application Scanner, can be used to create scripts for other custom or
off-the-shelf applications that you may want to measure.
Ganymede: Performance Endpoints and Qcheck
Performance Endpoints and Qcheck

How does Qcheck use Endpoints?
The Qcheck console can run tests between any two computers with Performance
Endpoints (or Qcheck itself) installed. When you install Qcheck, you
automatically install the appropriate built-in Endpoint for that computer. You
can download other endpoints free from the Ganymede web site.
From the Qcheck console you select the
Endpoints that will be used during the test.
Type of test-response time, throughput, or streaming.
Protocol-TCP, UDP, SPX, IPX.
Endpoints are "skinny" agents that emulate and drive traffic through the network
exactly like a real application, but without any application overhead.
1. When you tell Qcheck to run a test, it distributes test instructions to the
specified Endpoints. You can choose to measure response time,
throughput, or streaming traffic.
2. The receiving Endpoint (Endpoint 1) keeps its half of the test instructions
http://www.ganymede.com/products/endpoints/andqcheck.phtml (1 of 2) [3/14/2000 8:20:43 AM]
Ganymede: Performance Endpoints and Qcheck
Download Qcheck!
Ganymede Software's
network performance
and sends the other half to its partner (Endpoint 2). The Endpoints then
run the test.
3. At the end of the test, Endpoint 1 sends the test results back to the Qcheck
console. You can then use that data to determine the performance of a
particular Endpoint-to-Endpoint connection.
Figure 3. Select the test parameters on the Qcheck console and run your test.
Results are displayed on the Qcheck console.
http://www.ganymede.com/products/endpoints/andqcheck.phtml (2 of 2) [3/14/2000 8:20:43 AM]
Ganymede: Performance Endpoints and Pegasus
Performance Endpoints and Pegasus

How does Pegasus Network Monitor use Endpoints?
From the Pegasus server, you design and run multiprotocol, multi-application
monitoring scenarios. When you tell Pegasus Network Monitor to monitor a
connection (i.e., desktop-LAN-server, server-WAN-server), it distributes
instructions to the Performance Endpoints. These "skinny" agents emulate and
drive traffic through the network exactly like a real application, but without any
application overhead. Endpoints gather performance information about how well
the network is supporting a particular application and return performance
statistics and exceptions to the Pegasus server.
1. Pegasus Network Monitor tells an Endpoint how to emulate a particular
application by sending it monitoring instructions. The instructions
describe the type and amount of data to send and receive, the monitoring
schedule, and threshold values.
2. The receiving Endpoint (Endpoint 1) keeps its half of the monitoring
instructions and sends the other half to its partner (Endpoint 2). The
Endpoints then exchange a single transaction for each application being
monitored according to the predefined schedule.
http://www.ganymede.com/products/endpoints/andpegasus.phtml (1 of 6) [3/14/2000 8:20:52 AM]
Download Qcheck!
Ganymede Software's
network performance
3. At predefined periods, Endpoint 1 sends the monitoring results back to the

Pegasus server. In the event that a threshold has been exceeded, Endpoint
1 immediately sends a notification back to the server. You can use the
resulting data to identify, prioritize, isolate, and diagnose network
performance problems.
Figure 4. The Endpoints and monitoring instructions combine to monitor the

performance of applications across the network.
How does Pegasus Network Monitor use Application Scripts?

Application Scripts consist of commands, such as SEND and RECEIVE, as well
as script variables, such as the size of the buffer and the type of data in each
SEND.
Application Scripts are key to how we measure network performance with
Pegasus Network Monitor. Application Scripts model the real applications you
use between computers in a network. They make the same API calls to the
network protocol stacks that real applications make, causing the protocol stacks
to perform the same work involved in sending and receiving data.
Application Scripts are generally independent of the network protocol. This
means the same script can be used with any network protocol supported by the
Endpoints you're using. (A subset of the scripts supported only by Chariot,
called streaming scripts, requires a datagram protocol, such as IPX, RTP, or
UDP.)
Application Scripts are stored at the Pegasus console and are only delivered to
the Endpoints when you set up a monitoring schedule. Because of Pegasus'
flexibility, it can emulate the flow of almost any application in your network.
Application script parameters can be easily modified, allowing you to tailor
scripts to unique application models.
When Pegasus Network Monitor measures performance it will execute a single
transaction for each application being monitored (i.e., send a single e-mail,
create a PO with SAP). This minimizes the impact to the network from script
traffic.
A large library of Application Scripts is available with Pegasus and from the
on-line Application Script Library. Application Scanner can be used to create
scripts for other custom or off-the-shelf applications that you may want to
measure.
How do Endpoints enable traceroute analysis with Pegasus Network

Monitor?
On both a scheduled basis (ex. hourly), and when an exception occurs, Pegasus
uses Endpoints to initiate a traceroute analysis of every established and
configured connection. Endpoints execute traceroutes on a scheduled basis and
establish a baseline of route history and latency. When an exception (threshold
crossing) occurs, the Endpoint will immediately initiate a traceroute so that you
can compare the latency of the route taken when the exception occurred to the
baseline latency for the route taken.
Unlike a standalone traceroute, Network Monitor gives you the ability to
identify which hop(s) is causing the performance degradation by comparing the
hop latencies of the exception traceroute to the baseline traceroute at the
moment the exception occurred.
How do you AutoDiscover Endpoints with Pegasus Network Monitor?

Starting with Pegasus 2.1 and Performance Endpoints 3.4, you now have the
ability to AutoDiscover Endpoints that have an IP address. On the Pegasus
server, you configure a range of IP addresses on which you would like to
discover Endpoints. If an up level Endpoint is found, an Endpoint object is
created.
What are Dedicated Endpoints?

In addition to software Endpoints, Ganymede now offers dedicated
Endpoints-software Endpoints specifically tailored for hardware platforms, such
as the Cobalt RaQ server appliances. For more information, visit the
Performance Endpoint Download Page.
How does Pegasus Network Monitor use Endpoints?

From the Pegasus server, you select and configure the applications that you want
to monitor with Pegasus Application Monitor.
1. When you tell Pegasus Application Monitor to monitor an application on
a particular client, it distributes instructions to the Performance Endpoint
that resides on the client that you are monitoring. Pegasus Application
Monitor tells an Endpoint how to monitor a particular application by
sending instructions (A) for inspecting frames at the NDIS level so that
the Endpoint knows each packet by its port number.
2. The Endpoint passively monitors user-generated traffic (B) to measure
client, network, and server application performance. Pegasus Application
Monitor-enabled Endpoints can also be used to measure system statistics system CPU, disk I/O, and memory paging.
3. The Endpoint on the client gathers performance information about how
well particular applications are performing and returns performance

statistics and exceptions to the Pegasus Monitor Console (C). The client
Endpoint collects the performance statistics, and at predefined periods
sends the monitoring results back to the Pegasus server for display on the
Monitor Console. If a threshold has been exceeded, the client Endpoint
will immediately send a notification back to the Pegasus Server. You can
then use this data to identify, prioritize, isolate, and diagnose application
performance problems.
Figure 5. End-to-end Passive Performance Measurements. By passively

monitoring actual transactions and system statistics, you have the information
you need to triage application performance problems.
Which applications does Pegasus Application Monitor support?

Application Monitor will inspect frames at the NDIS level and recognize each
packet by its port number. Application Monitor currently supports cc: Mail,
POP3/ SMTP email, Lotus Notes, Exchange, NT File/Print, Web, FTP, DNS,
LDAP, Telnet, PointCast, Oracle, Sybase, MS-SQL, SAP R/3, PeopleSoft,
BaaN, and any custom application you define.
How do Endpoints enable traceroute analysis with Pegasus Application

Monitor?
On a scheduled basis (ex. hourly), and when an exception occurs, the client
Endpoint can initiate a traceroute analysis of preestablished logical connections
using Pegasus Application Monitor. Endpoints execute traceroutes on a
scheduled basis and establish a baseline of route history and latency. When an
exception occurs, a traceroute is immediately triggered by the Endpoint that has
experienced the exception. The trace is made between the originating Endpoint
and the connection involved in the exception (No E2 is required). You have the
option to preestablish logical connections whose baselines will be periodically
determined to collect a route history and can be used to execute a traceroute
when an exception occurs.
How do you AutoDiscover Endpoints with Pegasus Application Monitor?

Starting with Pegasus 2.1 and Performance Endpoints 3.4, you now have the
ability to AutoDiscover Endpoints that have an IP address. On the Pegasus
server, you configure a range of IP addresses on which you would like to
discover Endpoints. If an up level Endpoint is found, an Endpoint object is
created. For Pegasus Network Monitor, you would have to create the
connections as usual.
Ganymede: Performance Endpoint and the Cobalt RaQ
Performance Endpoint and the Cobalt RaQ

Download the Linux for MIPS Performance Endpoint
Cobalt RaQ Quick Install Guide
Cobalt RaQ Readme
Chariot and Pegasus share an important core technology: Performance
Endpoints. Performance Endpoints are skinny software agents that run on the
Cobalt RaQ Server, or in the background on existing clients and servers in your
network. The Linux for MIPS endpoint on RaQ 2:
Installs at the point of demarcation to measure
service quality
Actively monitors and measures the
performance of application traffic across the
network
Executes test scripts that emulate actual application flows end-to-end in a
network
Collects performance statistics and send them to the console or server,
which produces reports or alerts reflecting the response time, connectivity,
and throughput in your network
http://www.ganymede.com/products/endpoints/andraq.phtml (1 of 8) [3/14/2000 8:20:59 AM]
Download Qcheck!
Ganymede Software's
network performance
Generates TCP, UDP, and RTP traffic

Generates and measures multimedia streaming traffic like Voice over IP
(Chariot only)
Stores over two weeks of information in the event of a failure (Pegasus
only)
Collect data 24x7 (Pegasus only)
Cobalt RaQ 2
The Cobalt RaQ 2 server appliance from Cobalt Networks, Inc. provides
Ganymede customers with a dedicated endpoint, packaged in a single high rack
unit (1RU) industry standard enclosure. Pre-installed with the Linux operating
system and the Linux Performance Endpoint, the RaQ 2 can be deployed as a
dedicated endpoint.
Browser-based administration and maintenance
All administration and maintenance for Cobalt RaQ Servers is browser-based for
simple remote administration. The ISP or designated end-user administrator can
upgrade software and monitor the server from the browser. Maintenance agents
provide alerts if they detect potential problems, giving the administrator time to
take action before problems become serious. SNMP support means you can also
manage the Cobalt RaQ Server with the same standards-based network
management applications you use to manage other network devices.
Ordering Information
Part number: R28 143 EIURaQ 2 with 16MB DRAM, 4.3GB disk, single
Ethernet, Linux 2.0 O/S, Linux Performance Endpoint
The RaQ 2 hardware is sold by Cobalt Networks.
For the name of a distributor near you, contact:
Cobalt Networks, Inc.
555 Ellis Street
Mountain View, CA 94043

Phone: (888) 70-COBALT or (650) 930-2500
Fax: (650) 930-2501
Web: www.cobaltnet.com
Email: info@cobaltnet.com
Cobalt Networks, Europe
Pieter Twentlaan 10/2
NL-2242 CS Wassenaar
The Netherlands
Phone: +31 70.517.6375
Fax: +31 70.514.1446 Web: www.cobaltnet.com
Email: infoeurope@cobaltnet.com
Cobalt RaQ Quick Install Guide
These instructions are for installing on the Cobalt Web Server from a Web
browser running on a Linux computer. Note that you can install the endpoint
from computers running other platforms. In these cases, follow the instructions
below, omitting the step to mount the CD-ROM, if not required by your O/S.
Installation Instructions If you are going to install the endpoint after
downloading it from our Web site:
1. Go to the Endpoint Download page.
You will be asked to provide your name and email address to get to the
download page. This information is for our tracking purposes.
2. Click on the Linux for MIPS Endpoint (Cobalt RaQ).
You will be prompted for a directory where you want to save the file, for
example C:\Temp\Cobalt32.pkg.
3. A progress indicator lets you know when the transfer has completed.
After the download has completed, skip down to the instruction about
accessing the Welcome to Cobalt page on the Cobalt Web Server.
If you are installing the endpoint from the CD:
1. Put the CD-ROM in your CD-ROM drive.
Enter the following commands, assuming your CD-ROM drive device

name is /dev/cdrom and you are able to create a temporary directory
named cdrom:
2.
3.
4.
5.
6.
mkdir /cdrom
mount /dev/cdrom /cdrom
Access the Welcome to Cobalt page on the Cobalt Web Server.
(By default, this page is available by browsing at the Cobalt Web Server's
home page. If it is not, contact your Cobalt Web Server administrator.)
Click on the link to the RAQ Server Management section. The User Name
and Password Required dialog is shown.
Enter the user name and password for Administrator.
The Server Management Page is shown.
Press the Maintenance button followed by the Install Software button.
In the Software to install field, enter the location of the package. For
example: /cdrom/endpoint/linux/endcblr.pkg or C:\Temp\Cobalt32.pkg if
you downloaded the endpoint and are using Windows to install the
endpoint.
When prompted, enter the password for Administrator.
Press the Install a '.pkg' package button. After the endpoint is installed, a
message stating that the endpoint has been installed is shown.
After the installation is complete, use the UMOUNT command to
unmount the file system from the CD-ROM:
umount /cdrom
During installation you will see several status messages. Pay close
attention to the output. When the installation is successful, you see the
message Installation of endpoint was successful.
The installation script and temporary directory are not removed
automatically if the installation is successful. If you need the disk space
after installing the endpoint, you may delete the temporary directory and
installation script.
The endpoint requires a newer version of the glibc shared library to run
properly. While you can install the endpoint on a RaQ server with an older
version of glibc, you can not run any tests to the endpoint. This problem
does not occur with the RaQ2 server as they come installed with the newer
version of glibc. The version of glibc that you need is 2.0.7.9 (or newer).
You can determine which version you have by running the following
command from a shell on the RaQ server:
rpm -q glibc
If your RaQ system is running an earlier level of the software then you can
get the proper files for glibc from the Cobalt FTP site.
From your Cobalt RaQ server, use FTP to connect to
ftp.cobaltnet.com.
Log in with a user id of "anonymous" and a password of your
e-mail address.
Change to the pub/partners/ganymede directory.
Download the following RPMs:
glibc-*2.0.7-9.mips.rpm
kernel-*2.0.34-C18.mips.rpm
Install the RPMs using the "rpm -Uvh" command.
NOTE: These glibc's require texinfo and ldconfig to be installed before

glibc itself. Also, the glibc RPM must be installed with the --force and
--nodeps options to RPM. The kernel RPM must be installed before the
GDB one for it to work properly.
If you want to get more information about the Cobalt product you can
download the README from the ftp.cobaltnet.com site, which you may
want to do before installing the RPMs. The README is located in
pub/partners/ganymede directory as well.
Again, your RaQ server may already have the proper (or newer) versions
of some of these RPMs installed. If so, you don't need to install those
particular RPMs. As always, make a backup of your system before
installing new shared libraries.
Removing the Cobalt-Based Endpoint Package (Uninstall)

You must be logged in as the root user to remove the endpoint package.
Do not use the RPM command to remove the Cobalt Endpoint.
Next, enter the following command at a command-line:
/bin/sh /var/lib/cobalt/uninstallers/endpoint-3.3.uninst
After the script removing the endpoint package has completed, enter the
following command: /usr/admserv/cgi-bin/.cobalt/install/install.cgiAt the
prompt, press the CTRL -D keys. The endpoint is now removed.
What We Do During Installation
Here is what happens during the installation steps. The endpoint is
installed into the directory /usr/local/Ganymede. A directory is created
with the following
contents:
the executable programs
the README file
various install and uninstall programs
directory cmpfiles. This directory contains files with the .cmp file
extension. These are files containing data of different types, such as
typical text or binary data. These files are used by the endpoint
as data on SEND commands. The different data types can be used to
vary the data compression performance of your network hardware
and software.
file endpoint.ini
Our software ends any copy of the endpoint program currently running
and starts a copy of the newly-installed endpoint. You can run tests
immediately, without a reboot.
Our software displays information on how to update your system to have
the endpoint start automatically upon reboot.No changes are made to the
PATH environment variable of the root user.
Watch for new Application Scripts

We shall continue to add to our library of scripts in the coming months.
Watch our Web site for information about the availability of new or
updated scripts.
Cobalt RaQ Readme
For Original Cobalt RaQ Products (model number starts with R15)
In order for your RaQ product to use the Ganymede Endpoint software,
you must upgrade two elements of the Cobalt software: glibc and the
kernel.
At this time, this cannot be done via the one-button package file
installation mechanism.Using ftp and telnet, follow these steps:
As the root user, ftp the glibc and kernel rpm files to your RaQ.
These files are located at:
ftp://ftp.cobaltnet.com/pub/partners/ganymede/ The filenames are:
glibc-2.0.7-9.mips.rpm
kernel-2.0.34-C18.mips.rpm
Install these files using the following commands:
% rpm -U glibc-2.0.7-9.mips.rpm
% rpm -U --force kernel-2.0.34-C18.mips.rpm
List all installed rpm files using the following command to ensure
that the new files were installed correctly.
% rpm -qa
Reboot the server after installation to initialize the new files.
For Original Cobalt RaQ 2 Products (model number starts with R28)
The Cobalt RaQ 2 ships with newer versioned software that already
supports the Ganymede Endpoint software. Therefore, it is not necessary
to install the glibc and kernel files described above.
CONTACT INFORMATION
The Cobalt server appliances deliver simplicity, versatility, scalability, and
excellent performance so does our Customer Advocacy Technical Support
team! Use the following addresses if you have questions about your
product or are interested in a particular support program:
US and International customers can e-mail us at: support@cobaltnet.com
European customers can e-mail us at: support-europe@cobaltnet.com
Japanese customers can e-mail us at: support-japan@cobaltnet.com
Or call our US Mountain View office at: +1 (650) 623 2679
Ganymede: Operating System and Protocol Support
Operating System and Protocol Support

Endpoints have been tested with the following hardware, software, and
protocols. Click on an operating system for additional information on operating
system and protocol stack support. If you have questions about a product that
isn't listed here, please send e-mail to info@ganymede.com.
Cobalt RaQ or RaQ2
Yes Yes Yes
Yes
No
No 1
No
Compaq Tru64 UNIX
Yes Yes Yes
Yes
No
No 1
No
FreeBSD Unix
Yes Yes Yes
Yes
No
No 1
No
HP-UX
Yes Yes Yes
Yes
No
No 1
Yes
http://www.ganymede.com/products/endpoints/osproto.phtml (1 of 3) [3/14/2000 8:21:06 AM]
Download Qcheck!
Ganymede Software's
network performance
IBM AIX
Yes Yes Yes
Yes
No
No 1
Yes
IBM MVS
Yes Yes No
Yes
No
No 1
No
IBM OS/2
Yes Yes Yes
Yes
No
No 1
No
Linux
Yes Yes Yes
Yes
No
No 1
No
Microsoft Windows 2000
Yes Yes Yes
Yes
Yes No
1,2
Microsoft Windows 3.1
Yes Yes Yes
Yes
No
Microsoft Windows 95 w/
WinSock 2
Yes Yes Yes
Yes
Yes Yes
Yes
Yes Yes Yes
Yes
Yes Yes
Yes
Microsoft Windows NT 4
Yes Yes Yes
Yes
Yes Yes
Yes
Microsoft Windows NT 4
for Alpha
Yes Yes Yes
Yes
Yes No 1
Yes
Novell NetWare
Yes Yes Yes
Yes
No
No 1
No
SCO UnixWare
Yes Yes Yes
Yes
No
No 1
No
SGI IRIX
Yes Yes Yes
Yes
No
No 1
No
Sun Solaris for SPARC
Yes Yes Yes
Yes
Yes No 1
Yes
Sun Solaris for x86
Yes Yes Yes
Yes
Yes No 1
Yes
No 1
Yes
No
Pegasus Application Monitor does not support this endpoint;

however, supported endpoints can gather performance data on any
server connected to the client where the supported endpoint is
installed.
2
Ganymede has tested Application Monitor with beta versions of

Windows 2000; however, the beta versions have not yet proved
satisfactory. Keep checking our web site for the latest status on
testing with Windows 2000
TCP
Yes Yes N/A Yes
Yes Yes
N/A
RTP
No
No
No
N/A
UDP, IPX, SPX
Yes Yes N/A Yes
No
No
N/A
SNA, APPC
No
No
No
N/A
Yes N/A No
Yes N/A Yes
Ganymede Software
Ganymede Software Performance Endpoint

Download Form
You may freely download Ganymede Software's Endpoints from the links on
the following page, however, a copy of ChariotPegasus or Qcheck is
required to run the endpoints.
For information on evaluating or purchasing these products, click here.
*First Name:
*Email Address:
Title:
*Company:
*Address:
http://cgi.ganymede.com/endpoints.phtml (1 of 2) [3/14/2000 8:21:10 AM]
*Last Name:
Ganymede Software
Address:
*City:
*State:
*Zip/Postal Code:
*Telephone Number:
Fax Number:
*Where did you hear about Ganymede:
Submit Request
http://cgi.ganymede.com/endpoints.phtml (2 of 2) [3/14/2000 8:21:10 AM]
Ganymede: Creating Custom Application Scripts
Creating Custom Application Scripts

The real measure of end-to-end network performance is the response time and
throughput of an application transaction across the network. Application scripts
emulate the network flow of applications so you can measure and evaluate
performance during the transaction.
You can choose an Application Script from the Application Script Library or
you can use Application Scanner to create your own customized Application
Script. Application Scanner simplifies the process of creating and editing scripts
for custom-written and commercial applications.
How It Works
Download Qcheck!
Ganymede Software's
network performance
Application Scanner works by actually tracing an application transaction

through your network, then generating a script of the application. From the
client side, Application Scanner can trace an application that makes sockets calls
to TCP or UDP, then automatically generate scripts based on that trace.
An easy-to-use Wizard guides you through the steps, so that even an
http://www.ganymede.com/products/appscanner/index.phtml (1 of 2) [3/14/2000 8:21:15 AM]
Ganymede: Creating Custom Application Scripts
inexperienced user can create custom scripts. Application Scanner scripts are
compatible with Chariot v2.2 (or higher) and PegasusTM v1.2 (or higher).
After you generate a script with Application Scanner, you can modify script
variables to fit your specific testing or monitoring needs.
http://www.ganymede.com/products/appscanner/index.phtml (2 of 2) [3/14/2000 8:21:15 AM]
Ganymede: Application Scanner Technical specifications
Application Scanner Technical specifications

Ganymede Software's Application Scanner now gives you the ability to easily
create scripts that meet your needs. This simplifies the creation and editing of
scripts for custom written and commercial applications.
The real measure of end-to-end network performance is the response time and
throughput of an application transaction across the network. Ganymede
Software's Chariot and Pegasus Network Monitor measure and monitor network
performance by using Application Scripts that emulate the network flows of
these applications. You can choose an Application Script from the library
shipped with Chariot and Pegasus Network Monitor, or browse the Application
Script Library at www.ganymede.com/scriptlibrary. (These scripts cover a wide
range of transactions, from simple benchmarks to complex applications from
such vendors as Baan, SAP, and Lotus.) Or, you can create your own
Application Script with Application Scanner!
Download Qcheck!
Ganymede Software's
network performance
From the client side, Application Scanner can trace an application that makes
sockets calls to TCP or UDP, and automatically generate scripts based on that
trace. An easy-to-use wizard guides you through the steps, so that even an
inexperienced user can create custom scripts. Application Scanner scripts are
http://www.ganymede.com/products/appscanner/techspecs.phtml (1 of 2) [3/14/2000 8:21:17 AM]
Ganymede: Application Scanner Technical specifications
supported by Chariot v2.2 and Pegasus v1.2 (or higher). After generating a
script with Application Scanner, you can modify script variables to fit your
specific testing or monitoring needs. If you're an advanced Chariot or Pegasus
user, you can use the standalone Script Editor to create custom scripts without
tracing an actual application transaction.
Software Requirements
Windows 98
Windows NT 4.0 with Service Pack 4 or higher
Windows 95 with WinSock 2
Hardware Requirements
A Pentium processor or better
At least 16 MBytes of RAM
At least 16 MBytes of disk space
For Additional Information
For a detailed listing of capabilities and limitations, refer to the product
documentation.
Check out the Application Script Library for access to the most current
application scripts.
http://www.ganymede.com/products/appscanner/techspecs.phtml (2 of 2) [3/14/2000 8:21:17 AM]
Ganymede: Sales Contacts
Sales Contacts
*Zip/Postal Code:
*Country:
US
Submit Request
Download Qcheck!
Ganymede Software's
network performance
http://www.ganymede.com/salescontacts.phtml (1 of 2) [3/14/2000 8:21:21 AM]
Ganymede: Sales Contacts
http://www.ganymede.com/salescontacts.phtml (2 of 2) [3/14/2000 8:21:21 AM]
Ganymede: Application Script Library
Application Script Library

Baan Application Scripts
baan_all.zip (25,676 bytes)
This set of Ganymede Software "Business Application" scripts has been
developed to facilitate the testing of computer network infrastructure, when
Baan applications are being used or considered. They provide a representative
sample of Baan application transactions from each of the major Baan functional
areas. All of the scripts in this set are of a type that we describe as "Long
Connection." This means that the protocol connection handshake is not
measured in the test results.
BackWeb - Channel Subscription
bkwbsign.scr (620 bytes)

This script emulates subscribing to a new BackWeb channel.
BackWeb - Channel Update
bkwbupdt.scr (599 bytes)

This script emulates updating an existing BackWeb channel.
Castanet Tuner - Download
castdl.scr (739 bytes)
http://www.ganymede.com/support/scripts/library.phtml (1 of 8) [3/14/2000 8:21:27 AM]
This script emulates running Castanet Tuner for the download of a channel.
Castanet Tuner - Initial Run
castinit.scr (734 bytes)
This script emulates running Castanet Tuner for the first time.
Citrix ICA Application Scripts
citrix_all.zip (6,472 bytes)

The Citrix ICA scripts are a set of Ganymede Software Business Application
scripts, allowing you to choose the types of activities that characterize your
environment. We expect that in many cases only a few of the scripts will be
used in any particular test. Some of the scripts, such as the screen saver scripts,
represent network traffic that you will probably not want to see on a production
network, and the scripts exist mainly to demonstrate the negative effects of
allowing this traffic.
Credit Check - Long connection
creditl.scr (550 bytes)

This script emulates a series of credit approvals. A record is sent from Endpoint
1. Endpoint 2 receives the record and sends back a confirmation. The default
record size is 100 bytes.
Credit Check - Short connection
credits.scr (551 bytes)

This script emulates a series of credit approvals. A record is sent from Endpoint
1. Endpoint 2 receives the record and sends back a confirmation. The default
record size is 100 bytes.
Database Update - Long connection
dbasel.scr (666 bytes)

This is the most complex of the benchmarks. This script emulates a program that
requests a record from Endpoint 2, gets it, updates it and sends it back. Lastly,
Endpoint 1 receives a confirmation that the update was completed. The default
sizes for the request and the record are 100 bytes. (This script can be described
as an Inquiry followed by a Credit Check.)
Database Update - Short connection
dbases.scr (667 bytes)
This is the most complex of the benchmarks. This script emulates a program that
requests a record from Endpoint 2, gets it, updates it and sends it back. Lastly,
Endpoint 1 receives a confirmation that the update was completed. The default
sizes for the request and the record are 100 bytes. (This script can be described
as an Inquiry followed by a Credit Check.)
FTP Get
ftpget.scr (1,040 bytes)
This script emulates TCP/IP's FTP application. The default file size is 100,000
bytes.
FTP Put
ftpput.scr (1,040 bytes)

This script emulates TCP/IP's FTP application. The default file size is 100,000
bytes.
File Transfer (Receive) - Long connection
filercvl.scr (533 bytes)

This script emulates requesting a file and getting it back. The request from
endpoint 1 defaults to 100 bytes. The default file size is 100,000 bytes.
File Transfer (Receive) - Short connection
filercvs.scr (534 bytes)

This script emulates requesting a file and getting it back. The request from
endpoint 1 defaults to 100 bytes. The default file size is 100,000 bytes.
File Transfer (Send) - Long connection
filesndl.scr (486 bytes)

This script emulates sending a file from Endpoint 1 to Endpoint 2, and getting a
confirmation back. The default file size is 100,000 bytes.
File Transfer (Send) - Short connection
filesnds.scr (487 bytes)

This script emulates sending a file from Endpoint 1 to Endpoint 2, and getting a
confirmation back. The default file size is 100,000 bytes.
Headliner - Initial Run
hdlninit.scr (607 bytes)
This script emulates the initial run of Headliner.

Headliner - Update
hdlnupdt.scr (612 bytes)
This script emulates subsequent updates of Headliner.
IP/TV - Audio Stream
iptva.scr (394 bytes)

Cisco System's IP/TV application, MPEG audio streams.
IP/TV - Video Stream
iptvv.scr (394 bytes)

Cisco System's IP/TV application, MPEG video streams.
Inquiry - Long connection
inquiryl.scr (629 bytes)

This script emulates a typical client/server transaction. Endpoint 1 sends a
request to Endpoint 2, which sends a reply back. Both the request and reply
default to 100 bytes. The script variables let you add delays, and change the
send and receive buffer sizes.
Inquiry - Short connection
inquirys.scr (630 bytes)

This script emulates a typical client/server transaction. Endpoint 1 sends a
request to Endpoint 2, which sends a reply back. Both the request and reply
default to 100 bytes. The script variables let you add delays, and change the
send and receive buffer sizes.
Lotus Notes Application Scripts
lotus_all.zip (12,224 bytes)

developed to facilitate the testing of computer network infrastructure, when
Lotus Notes applications are being used or considered. They provide a
representative sample of Notes application transactions. All of the scripts in this
set are of a type that we describe as "Long Connection." This means that the
protocol connection handshake is not measured in the test results.
Microsoft RDP Application Scripts
ms_all.zip (5,890 bytes)

The Microsoft RDP scripts are a set of Ganymede Software Business
Application scripts which let you choose the types of activities that characterize
your environment. We expect that in many cases only a few of the scripts will
be used in any particular test. Some of the scripts, such as the screen saver
scripts, represent network traffic that you will probably not want to see on a
production network, and the scripts exist mainly to demonstrate the negative
effects of allowing this traffic.
NetMeeting - Audio
netmtga.scr (392 bytes)

Emulates sending an audio stream using Microsoft NetMeeting v2.1 over a 100
Mbps Ethernet LAN.
NetMeeting - Video
netmtgv.scr (392 bytes)

Emulates sending a video stream using Microsoft NetMeeting v2.1 over a 100
Mbps Ethernet LAN.
NetShow
netshowu.scr (386 bytes)

Emulates the Microsoft NetShow application.
Network News
nntp.scr (1,025 bytes)

This script emulates the transfer of network news across the Internet, using the
NNTP protocol.
Oracle Financials Application Scripts
oracle_all.zip (23,966 bytes)

The Oracle Financial Applications scripts are Ganymede Software scripts based
on a standard set of benchmark transactions. These transactions are used to
measure the performance of servers that run the application and database
components of the Oracle applications. Because the Oracle financial
applications can be executed in a three-tier configuration, each of the
transactions has two scripts associated with it, a Tier 1 and a Tier 2 script. If you
have, or plan to, deploy the applications on separate server computers for the
application and database components, you can use the tier 1 scripts to emulate
the traffic between the end user computer and the application server, and the tier
2 scripts to emulate the traffic between the application server and the database
server. We expect that in many cases you will only want to use either the tier 1
or the tier 2 scripts, depending on the portions of the your network that you want
to test at the time. Both types of scripts may be combined in a single test to
simultaneously test the network paths between all three types of computers
involved in a transaction.
Packet Blaster - Long Send
packetl.scr (490 bytes)
The PACKETL script sends packets, as quickly as possible, without waiting for
any kind of response. This is NOT a good test for gathering performance
information. Measurements can be inaccurate, because the script ends without
waiting for the receiving side to catch up. This test uses the FLUSH script
command. While it has no effect on TCP/IP, it causes APPC to send data
immediately, rather than waiting to fill buffers.
Packet Blaster Reversed - Long Receive
packetlr.scr (499 bytes)

The PACKETLR script receives packets, as quickly as possible, without waiting
for any kind of response. This script is similar to PACKETL.SCR, but Endpoint
1 issues Receives instead of Sends. Measurements are more accurate, since
Endpoint 1 knows exactly how many bytes have been received successfully in
each timing record.
PointCast Network - Version 1
pntcast1.scr (623 bytes)

This script emulates content updates for PointCast Network version 1.
PointCast Network - Version 2
pntcast2.scr (623 bytes)

This script emulates content updates for PointCast Network version 2.
Real Audio - Audio/Video
realmed.scr (399 bytes)

Emulates Real Audio Audio/Video Applications by RealNetworks.
Real Audio - CD Streaming
realaud.scr (387 bytes)

Emulates Real Audio CD Streaming Applications by RealNetworks.
Receive E-mail
pop3.scr (896 bytes)

This script emulates typical e-mail transfers. The default size of an e-mail
message is 1,000 byte, with an additional 20-byte header.
SAP R/3 Application Scripts
sap_all.zip (9,190 bytes)

developed to facilitate the testing of computer network infrastructure, when SAP
R/3 applications are being used or considered. They provide a representative
sample of SAP R/3 application transactions. All of the scripts in this set (except
SAP_v3_Login) are of a type that we describe as "Long Connection." This
means that the protocol connection handshake is not measured in the test results.
Send E-mail
smtp.scr (821 bytes)

This script emulates typical e-mail transfers. The default size of an e-mail
message is 1,000 byte, with an additional 20-byte header.
Telnet
telnet.scr (592 bytes)

This script emulates the byte-by-byte transfer of characters in TCP/IP's Telnet
application.
Voice Over IP Send
voips.scr (382 bytes)

Emulates a voice over IP session conducted by an equipment vendor who is
qualifying their equipment.
Web Graphics Request
httpgif.scr (602 bytes)

This script emulates the transfer of graphics files from an HTTP server. The
default file size is 10,000 bytes.
Web Text Request
httptext.scr (603 bytes)

This script emulates the transfer of text files from an HTTP server. The default
file size is 1,000 bytes.
Ganymede: Chariot Technical Support
Chariot Technical Support

View product information, get answers to frequently asked questions, download
third-party software and download documentation for Chariot.
http://www.ganymede.com/support/chariot/index.phtml (1 of 2) [3/14/2000 8:21:31 AM]
Ganymede: Chariot Technical Support
http://www.ganymede.com/support/chariot/index.phtml (2 of 2) [3/14/2000 8:21:31 AM]
Ganymede: Chariot Service Updates

There are no service updates available for Chariot at this time.
http://www.ganymede.com/support/chariot/chariot_updates.phtml (1 of 2) [3/14/2000 8:21:34 AM]
Ganymede: Chariot Service Updates
http://www.ganymede.com/support/chariot/chariot_updates.phtml (2 of 2) [3/14/2000 8:21:34 AM]
Ganymede: Chariot FAQ
Chariot FAQ
Why do my graphs sometimes drop to zero?
How do I increase the load during a test?
What do the '95% confidence interval' and the 'relative precision' mean?
I'm having trouble running a long (or fixed) duration test to completion
Why is the Aggregate throughput value larger than the theoretical maximum?
Click here if you have a question that is not in the list above.
Why do my graphs sometimes drop to zero?
Graphs drop to zero during inactive times of 25 ms or longer. Inactive times
occur when an endpoint pair is not generating network traffic. You can view the
http://www.ganymede.com/support/chariot/chariot_faq.phtml (1 of 4) [3/14/2000 8:21:38 AM]
inactive times in the Timing Records Details from which the graphs are
generated. There are three primary cases that cause inactive times:
Sleeps set by the user in editing the test script.
Sharing of resources with applications or other endpoint pairs delay a
pair's CPU access.
Scripts with complex outer loops running over relatively slow
connections (i.e., the two FTP scripts).
How do I increase the load during a test?

I'm glad you asked. The trick is to edit the variable "initial_delay" in the script
for each pair, and make it larger for each succeeding pair. Then, rather than
work out how long each pair should run, simply set the Run Option to run for
the desired time. If building this type of test is something you will be doing
repeatedly, you may want to Save a set of scripts with this variable change
already done.
What do the '95% confidence interval' and the 'relative precision' mean?
Chariot calculates averages for throughput, transaction rate, and response time.
The 95% confidence interval and the relative precision are statistical
descriptions of the consistency of those values. With apologies to my old
statistics professor, the simplest way to look at it is to tack the same units as the
average onto the 95% confidence interval, and say the result is the 'plus or
minus' amount. For the relative precision, think of it as the 'plus or minus'
amount as a percentage. So, with actual test results such as throughput average
of 354.9KB/s and 95% confidence interval of 18.9 and relative precision of 5.3,
the throughput average is 354.9 KB/s, +/- 18.9 KB/s, or +/- 5.3%. That's not
strictly correct, but it is a useful way to think of it. For a more detailed
description, see our manual or online help, or even your friendly neighborhood
statistics professor.
I'm having trouble running a long (or fixed) duration test to completion.
By far the most likely cause is that you are inadvertently creating far more
timing records that you need. The easy way to correct this problem is to modify
the script that you are using, to perform many more transactions per timing
record. The transaction count is usually specified as the variable parameter for
the second LOOP verb in a script. As a rule of thumb, try a multiple of 10 for
each hour that you plan to run the test, for example, multiply the
"transactions_per_record" by 10 for 1 hour, 20 for 2 hours, and so on.
Remember, if you are making this change to a test that contains many pairs, you
can change all of the pairs at once, by selecting all pairs, and clicking on the
"edit pair" button.
Why is the Aggregate Throughput value larger than the theoretical

maximum?
The basic reason is that not all of the pairs in a test are sending simultaneously,
while the summation of the timing records is done as though they were. There
are several reasons why an endpoint may not be sending data at times. The most
obvious is where a non-zero value is coded on a SLEEP variable that is outside
of the timing loop. Another possibilty is that several pairs are defined in one
endpoint, and the operating system suspends one of the tasks while another runs.
To determine if this is happening, examine the timing records of the test in
question. You will find that some of them contain positive values in the column
labelled "Inactive Time". Look at it this way, there are 2 pairs running across a
128 kbps link, one is sending and measuring 100 kbps, while the second pair is
stuck at a point in the script outside of the timing loop. When the first pair
finishes sending the second pair is freed, by the operating system or protocol
stack, to begin sending, while the first pair is now held up. Both pairs, in other
words, report throughput of 100 kbps, for an aggregate of 200 kbps. An
explanation of this is documented. Search for "inactive time" and select the
entry "how inactive time affects aggregate values".
Unanswered questions?
This Web page contains answers to some of the most frequently-asked questions
about our products. It is updated often, so if you don't find the answer to your
question today, check back soon. We rely on our customers to provide us with
the feedback that helps this page be filled with the most useful and current
information. We welcome your suggestions for improvements and for new
issues you'd like to see addressed on this page.
Send your comments to us via e-mail at support@ganymede.com
Registered users can also reach our customer care team at:
888 GANYMEDE (888 426-9633) toll free in the USA
919-469-0997 (voice)
919-469-5553 (fax)
If you don't find the answer to your question listed above, consult the "Common
Problems" section of the User Guide. If you still need assistance, contact our
customer care team.
Ganymede: Chariot Specifications
Chariot Specifications
WINDOWS NT/2000 CONSOLE REQUIREMENTS
Microsoft Windows NT for x86 v4.0 or Windows 2000
Protocols
TCP/IP
TCP/IP WinSock2 stack included with Windows NT
(NT Service Pack 3 or higher recommended)
SNA
Microsoft SNA Server stack>
(v4.0 recommended)
IBM Communications Server for Windows NT v5.0
http://www.ganymede.com/support/chariot/chariot_specs.phtml (1 of 3) [3/14/2000 8:21:42 AM]
IBM Personal Communications for Windows NT

(v4.11 or higher)
IPX/SPX
IPX/SPX stack included with Windows NT
WINDOWS 95/98 CONSOLE REQUIREMENTS

Microsoft Windows 95 or Windows 98
Protocols
TCP/IP
TCP/IP WinSock2 stack included with Windows 98
(available separately with Windows 95)
SNA
IBM Personal Communications for Windows 95/98
(v4.11 or higher)
IPX/SPX
IPX/SPX stack included with Windows 95/98
AVAILABLE CONFIGURATIONS
Windows NT 10,50,200, and 500 concurrent connections.
Windows 95/98 10 or 50 concurrent connections.
OPERATING SYSTEMS SUPPORTED

Windows 3.1, 95, 98, NT x86, and NT Alpha
Novell NetWare
IBM AIX, OS/2, and MVS
Compaq True64 Unix
HP-UX
Linux x86 and MIPS
SGI IRIX
SCO UnixWare
Sun Solaris Sparc and x86
Ganymede: Chariot Documentation
Chariot Documentation
Chariot 3.1 User Guide (6/99)
Provides the most useful information about Chariot. It describes the interface to
Chariot, how it works, and what kind of information it provides.
Chariot User Guide (2.0M, 183 pages)
Messages and Application Scripts Manual (10/99)

Provides detailed information about messages and working with application
scripts.
Messages and Application Scripts Manual (780K, 216 pages)
http://www.ganymede.com/support/chariot/chariot_docs.phtml (1 of 2) [3/14/2000 8:21:46 AM]
Ganymede: Chariot Documentation
Chariot Programming Reference (6/99)

Provides information about using the API to write programs or Tcl scripts that
use and extend the capabilities of Chariot.
Chariot Programming Reference (724K, 234 pages)
Ganymede Software documentation is provided in Adobe Acrobat format

(.PDF). If you don't have Acrobat installed, click on the button below.
http://www.ganymede.com/support/chariot/chariot_docs.phtml (2 of 2) [3/14/2000 8:21:46 AM]
Ganymede: Chariot Third Party Updates
Chariot Third Party Updates

This page provides links to the most recent versions of software and operating
systems necessary to run Chariot.
Operating Systems
Windows NT
Windows 95
Windows 98
Browsers
Download Internet Explorer v4.01
Download Internet Explorer v4.01 Service Pack 1
http://www.ganymede.com/support/chariot/chariot_third.phtml (1 of 2) [3/14/2000 8:21:49 AM]
Ganymede: Chariot Third Party Updates
Download Netscape Communicator v4.5
http://www.ganymede.com/support/chariot/chariot_third.phtml (2 of 2) [3/14/2000 8:21:49 AM]
Ganymede: Chariot Tools and Utilities
Chariot Tools and Utilities

Creating TCP Connections
A Chariot user recently had a need to create and run tests, where the
device under test would have a very large number of static TCP
connections open. To help them achieve their objective, we created a
simple utility program that merely opens connections between a pair of
TCP/IP computers. If you are a Chariot user and have a similar need,
contact Ganymede Software Customer Care for additional details.
SETALIAS
The SETALIAS program is used to set or change the APPC name of an
NPE running as a Windows NT client in a Microsoft SNA Server
environment. When the program is run with no parameters, it displays the
current APPC alias. When given a parameter, it sets or updates the APPC
alias. To make the alias take effect, stop and start the SnaBase Service, or
re-boot the computer.
http://www.ganymede.com/support/chariot/chariot_tools.phtml (1 of 2) [3/14/2000 8:21:52 AM]
Ganymede: Chariot Tools and Utilities
http://www.ganymede.com/support/chariot/chariot_tools.phtml (2 of 2) [3/14/2000 8:21:52 AM]
Ganymede: Chariot Testing Tips
Chariot Testing Tips

This section includes some performance testing tips and techniques we think
you'll find helpful. As you become more experienced with Chariot, you'll
uncover your own ways to use this software more productively. Contact us with
what you learn; we'll share your lessons with other users via the Web and in
upcoming releases.
Using Chariot for Network Performance Testing
Using Chariot for Stress Testing
Avoiding Too Many Timing Records
Maximizing Throughput Over Fast Ethernet
Testing Unstable Environments
http://www.ganymede.com/support/chariot/chariot_tips.phtml (1 of 25) [3/14/2000 8:22:07 AM]
Chariot Endpoint Machine Resources Guideline

APPC Performance with MVS/VTAM
Emulating Multiple Users
Using Chariot for Network Performance Testing
Here are suggestions for creating effective, repeatable performance tests. In
general, choose the following options for performance testing:
Report timings using Batch
The alternative to reporting timings in Batch is Real-time reporting.
Real-time reporting causes timing records to flow across the same
network you are measuring. This can really disturb what is being
measured-potentially changing your results by several hundred percent.
Run for a fixed duration or run until any pair completes
Running for a fixed duration or until any pair completes causes all the
pairs to end at the same time. Otherwise, results become skewed as some
pairs keep running (thus getting more bandwidth) while others have
completed.
Do not use an endpoint in the same computer as the console
You do not want the endpoint and console to compete for CPU cycles or
for access to the protocol stacks. If you absolutely have to test with just
two computers, use RUNTST for your performance testing, not the GUI
console.
Do not poll the endpoints
Polling causes extra flows, slightly disturbing what is being measured.
Only poll if you suspect something is wrong, in which case, start your test
over anyway.
Do not validate data upon receipt
Data validation consumes extra CPU cycles at the endpoints. Use only
when you suspect elements in the network may be corrupting the data
they are sending.
Set all SLEEP times to 0

Non-zero sleep times delay what is being measured.
Set SEND data type to ZEROS (unless testing compression in your
network)
All zero data consumes the fewest CPU cycles at the endpoints.
Do not set the number of repetitions higher than 1 (when using FTPGET or
FTPPUT scripts)
Not setting the number of repetitions higher than 1 avoids an aggregate
throughput value greater than the network's capacity. (Exceeding the
network's capacity can only occur with non-zero SLEEP times.)
If you want to test for maximum throughput, use the FILESNDL script
Change the file_size variable from 100,000 bytes to 10,000,000 or more.
This script sends a large amount of data from endpoint 1 to endpoint 2,
which sends a confirmation back to endpoint 1.
To evaluate full duplex data transfer, choose a Chariot script and run it in
both directions at the same time between a pair of machines
To set this up between computers with addresses A and B, run one script
from A to B and the other from B to A by reversing endpoint 1 and
endpoint 2.
Do not create too many timing records
This has several bad effects. Each timing record at the console uses 40
bytes of memory. Long-running tests can generate so many timing
records that the console runs out of memory. Even if it does not run into
virtual memory problems, the file size to store the test can take many
megabytes, and the overall performance of the system becomes sluggish
because of the paging that has to take place.
When comparing IPX and IP traffic, compare SPX to TCP and IPX to UDP
Typically, SPX and TCP, being connection-oriented protocols, have a
more sophisticated form of flow control. Therefore, in general, the
connection-oriented protocols outperform the datagram protocols. For
shorter transactions, however, datagrams outperform connection-oriented
protocols.
SPX II closely simulates NCP traffic and is a vast improvement over SPX
SPX II is available on NT4, OS/2, and NetWare 4.X. To use SPX II,
choose the SPX protocol in Chariot. Run the test between two endpoints
able to run SPX II; if both sides are capable, SPX II is used automatically.
When using IPX or UDP, adjust the Datagram parameters for best test and
media performance
To simulate actual user applications, use specific scripts such as FTPGET
or TELNET. If you need something special, we can create a custom script
for you and then make it available to all our customers.
Using Chariot for Stress Testing

Ganymede Software's suggestions for stress testing Chariot intentionally conflict
with our suggestions for performance testing. In performance testing, the
objective is to increase performance of the network under actual working
conditions. Stress testing, by comparison, generates a lot of extra network
traffic-really stressing your hardware and software. The following suggestions
help you make better use of Chariot while stress testing:
Run for a fixed duration
Decide how long to stress your network and endpoint computers. Do
some experimenting. You do not want to return thousands of timing
records to the console that you are not going to use anyway.
Adjust the transactions_per_record script variable
Set a low value for the number_of_timing_records script variable, and a
high value for transactions_per_record. Multiply your transactions for
each record by 10 times the number of hours your test runs. For example,
increase the test by 10 times for 1 hour, 100 times for 10 hours, and so on.
The number_of_timing_records value is ignored when running for a fixed
duration. Experiment with high transactions for each record settings to
avoid trashing the console with too many timing records. The console
feels sluggish when dealing with more than 10,000 timing records.
Report timings using real time
Real time reporting causes timing records to flow across the network as
they are generated, increasing the amount of network traffic.
Regularly poll the endpoints
Regularly polling the endpoints causes extra flows, outside the pattern of
scripts and timing records.
Validate data upon receipt
Validate all data transferred among endpoints during stress conditions to
see if there are any problems with your network hardware and software.
Use random SLEEP times
Use the uniform distribution of sleep times to simulate many users,
pausing slightly between transactions. Choose a range of 0 to 2 seconds
(2,000 milliseconds).
Set your SEND data type to NOCOMPRESS
NOCOMPRESS is the toughest data to compress. You will keep busy
network components that compress as the components try to find patterns
in the data.
Avoiding Too Many Timing Records

When you run a test for a fixed duration, Chariot ignores the
number_of_timing_records value specified in the scripts. It runs as many
transactions during that time as it can.
When you run a test for a duration much greater than typically required, you
greatly increase the number of timing records the endpoints generate. Chariot
becomes cumbersome when the number of returned timing records is above
10,000.
For example, you may run a test with one endpoint pair which generates on your
network 100 timing records in 20 seconds. If you run the same test with the
fixed duration set to one hour, Chariot generates approximately 18,000 timing
records. Additional pairs multiply the number.
When running a test for a fixed duration, Ganymede Software strongly

recommend increasing the scripts' transactions_per_record values so the test's
total number of timing records is less than 10,000.
To reduce the number of timing records:
1. In the Test window, click on the toolbar Add pair or Edit pairs icon.
When the dialog box appears, you can open or edit a script, and change
the endpoint pair's addresses and protocols.
2. In the Add or Edit an Endpoint Pair dialog box, click on the Open a script
file button which opens a list of scripts. Once you have chosen a script,
click on the Edit this script button.
3. An Edit a Script dialog box appears. Double-click on
transactions_per_record, at the bottom half of the dialog box.
4. Increase by ten times the Current Value for the transactions_per_record.
For example, if the number of transactions_per_record is 50, change the
number to 500. Save your changes by pressing OK on the open dialog
boxes.
5. Open Set run options from the Run menu. Click the Run for a fixed
duration button. In the Duration field, select one (1) minute.
6. Run the test and view the results. Using the Raw Data Totals tab, look at
the Number of Records. This is the total number of timing records
generated in one minute. You would prefer about 50 to 100 records per
pair for good statistical significance. If the results contain more than a
total of 10,000 timing records, go back and further increase the
transactions_per_record. Otherwise, continue to the next step.
7. Increase the scripts' transactions_per_record to match the duration of
your test.
Here is the formula to determine the number of transactions per record:
transactions_per_record
= (minutes to run) x (transactions_per_record in the one minute test)
Example:
In the steps above, you entered 500 for the script's
transactions_per_record and ran the test for one minute. The results
should have about 300 timing records per pair (100 per 20 seconds = 300
per minute). Three hundred timing records per pair is a fine number if you
are not running hundreds of concurrent endpoint pairs.
Now you would like to run the test for the whole weekend (48 hours).
Consider the math:
= (60 minutes per hour) x (48 hours) x (500 transactions per record)
= (2880 minutes) x (500 transactions per record)
transactions_per_record = 1,440,000
Open the script and change the transactions_per_record value to
1,440,000. Then, change the Duration to 48 hours in the Set Run Options
dialog.
Your test is ready to run over the weekend. Start it and go home.
Maximizing Throughput Over Fast Ethernet Using TCP/IP and Windows

NT
Several adjustments can be made to get the maximum throughput from a given
computer using Chariot. Some experimentation is warranted, however your
mileage may vary.
There appears to be a processor limit with Windows NT of about 80 Mbps for
P166's and just over 100 Mbps (requiring duplex enabled hardware) on P200's.
Note that Chariot measures application data throughput, which does not include
frame headers, interframe gap, LLC SAP headers, SNAP headers, or TCP/IP
headers. SQE heartbeat, collisions, and broadcast frames also increase the
difference between throughput and theoretical wirespeed, as do
acknowledgments. Consequently, 80-90% of wirespeed constitutes excellent
results. We experimented with identical machines with their NIC's directly
connected over crossover cable so there was minimal latency.
What to do always:
Report timings using Batch - The alternative to Batch, Real-time
reporting, causes timing records to flow across the same network you're
measuring. This can really perturb what's being measured- potentially
changing your results by several hundred percent.
Run for a fixed duration, or Run until any pair completes - These run
options cause all the pairs to end at the same time. Otherwise, your results
get skewed as some pairs keep running (thus getting more bandwidth)
while others have completed.
Don't use an endpoint in the same computer as the console - You don't
want the endpoint and console to be competing for CPU cycles or for
access to the protocol stacks.
Don't poll the endpoints - This causes extra flows, slightly perturbing
what's being measured. Only poll if you suspect something's gone wrong,
in which case you should probably start over anyway.
Don't validate data upon receipt - Data validation consumes extra CPU
cycles at the endpoints.
Set all SLEEP times to 0 - Non-zero sleep times obviously delay what's
being measured.
Set your SEND data type to ZEROS (unless testing compression in your
network) - All-zero data consumes the least RAM at the endpoints.
Don't set the number of repetitions greater than 1 (if using the FTPGET or
FTPPUT scripts)
Do not run other software on the endpoint computers, and turn off screen
savers.
Do not use the console computer as an endpoint. If the console computer
must be an endpoint, use runtst.exe to run the test from a command line,
rather than the GUI.
Use the script filesndl.scr.
Use the symmetrical endpoint pairs. This is set up computer A as
Endpoint 1 in pair one, and computer A as Endpoint 2 in pair 2. Add pairs
2 at a time.
For multimedia scripts, don't set you file size or buffer size too low when you
are sending at a high data rate, this will generate too many timing records. This
avoids an aggregate throughput value that's greater than the network's capacity
(which can only occur, by the way, with non-zero SLEEP times). See in the
Viewing the Results chapter on page 25 for more information.
What to experiment with:
In the script filesndl.scr, increase the file size. The optimum size will almost
certainly be 1M (10 times the default of 100k), but 10m is worth experimenting
with.
In the Windows NT registry set the TcpWindowSize:
To do this, run regedt32.exe, and navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\Tcpip\Parameters
Go to Edit, Add value, and add "TcpWindowSize" as a REG_DWORD.
The maximum value available is 64K. Matching the TcpWindow Size to
the underlying MTU size minus the IP header will improve efficiency.
This means multiples of 1460, 1457, or 1452, depending on Ethernet
implementation.
Back in the Chariot script, change the send_buffer_size and
receive_buffer_size to 1/2 the registry value of TcpWindowSize. Curiously, 40
times 1460 (i.e. 58,400) seemed to be the best value.
Testing Unstable Environments

Fundamentally, Chariot was designed to test stable network connections. If a
connection drops, Chariot will not attempt to reestablish it, and it will end the
test. The design rationale for this was that the meaning and interpretation of
results can be badly skewed if Chariot is spending time doing work (i.e.,
reestablishing a connection) that is not part of the script. However, there are
network environments that see outages of several minutes as normal. The
Internet and wireless networks are two possibilities.
For short tests, this is not likely to be a problem. Long tests, however, require
some different ways of thinking about the testing process. In either case, keep in
mind that you may want to set the Run options not to 'Stop run on initialization
failure.'
Using the Datagram Protocols (UDP and IPX)
A surprisingly simple solution to overcoming lost connections is to not lose
them to begin with. Perhaps you would like to run a test for several hours over
TCP on a network on which individual endpoints may become disconnected for
a few minutes at a time. If this happens, the TCP stack will decide the
connection has been lost and tell Chariot, ending the test. It is possible to go into
the TCP stack parameters and configure them to retry the connection, or to take
longer to timeout, but it is a cumbersome task, and must be done on each
machine that will act as an endpoint in your test. If you switch to UDP, there is a
more elegant method. UDP uses the same IP layer as TCP. It's not exactly the
same thing as TCP, but it's darn close, and it moves the connection oriented
controls into the application layer (i.e., Chariot) where they are easily adjusted
from one central point.
Likewise, the above arguments all apply to IPX in the NetWare environment.
Look at a Chariot test screen. Click on the Run menu item, and then on the Set
run options.... When the Run options window appears, go to the Datagram tab.
There are three items that can be configured here. We are only interested in the
2nd and 3rd, the Retransmission Timeout and the Number of retransmits before
aborting. The maximum values these fields can be set to are 99,999 milliseconds
(100 seconds) and 999, respectively. If one were to set the retransmission
number to the maximum of 999, and the timeout value to 300 ms, once a test has
begun, an individual node could be disconnected from the network, and as long
as it was reconnected within 5 minutes, the test would continue to run.
So the question becomes, how long a network outage do we need to be able to
absorb? If the number of retransmits is set to 999, then take the desired
maximum outage time, convert it to ms, and divide by 1000. Thus 1 min needs
60 ms, 5 min requires 300 ms, 10 min, 600 ms, etc. The maximum possible time
a test can be set to continue after a lost connection is 27 hrs, 45 min.
What kind of numbers will this produce? It might be wise to export the resulting
timing records to a spreadsheet, and perhaps set up a macro to massage the data
however we would wish. Chariot will report the aggregate throughput, etc, and
that value will average in the 'down time' from any temporarily lost connections.
The detailed timing records will provide the average throughput for much
smaller intervals, and one could compare the rates significantly above zero to
see when a connection is working as opposed to when it isn't. When a
connection had been lost, and for how long, can readily be determined from the
detailed timing records. The timing records will display very close to the same
time interval while the connection is up, and a large jump in time whenever
there was a down time. The elapsed time will inform us when it happened, and
the measured time will tell us for how long. The accuracy of these values will be
affected by the timeout setting, and thus we would want to keep the timeout
setting to the lowest value that copes with the networks expected outages.
Chariot's line graphs will display a diagonal line dropping to zero during outage
periods, making them easy to spot.
The Datagram tab in the Chariot test results will reveal how many datagrams
were lost, retransmitted, etc. A little massage of this data will extract the
retransmits due to long outages, allowing us determine if there are many short
connection drops. Once again, a spreadsheet export may be helpful here.
Batch test execution
It is also possible to run tests in series, rather than running one large one.
Chariot comes with command line executables to facilitate running tests in batch
files or with a scripting language. Note that an important consideration in the
test setup is the Run option, Stop run on initialization failure. In testing unstable
environments, one would likely want this option turned off.
Runtst.exe will run a previously set up test and save the results to either the
original file, or to a new one.
RUNTST test_filename [new_test_filename]
The test_filename parameter is the Chariot test file to run. If the
new_test_filename parameter is provided, the test setup and results are
saved to this new file; otherwise, results are saved to test_filename.
Fmttst.exe can be used to output the test results to spreadsheet to allow multiple
tests to be easily compared in a single file.
FMTTST tst_filename [-h] [-s] [-c]
The tst_filename parameter is the Chariot test file to format.
Options:
-h Creates HTML output
-s Creates spreadsheet output (with file extension .WK3)
-c Output according to export configuration>
Writes ASCII text to stdout (unless -s is specified)
These utilities could be used to run tests back to back, or perhaps the same test
over and over, so that a test that may have ended because of a temporary
problem can be restarted immediately.
There is an excellent example of a perl script that expands Chariot's capabilities
in this way on this web site.
Chariot Endpoint Machine Resource Guidelines

Determining the computer requirements for a given Chariot endpoint can be
challenging. There are many variables involved, such as processor speed,
operating system, protocol stack, memory, disk space, and the underlying
network. To determine the requirements, you must first define how you plan to
use Chariot. Do you want to generate data as fast as possible to determine
network performance, stress a local resource such as an adapter card or protocol
stack, or just generate some network traffic? The type of information you need
depends upon your usage.
Generating Maximum Throughput
The main factors in getting the most throughput from a computer are CPU speed
and memory. You need a CPU that is fast enough to match your network
capacity, and with enough memory to hold the code and data used for the test.
For best throughput, we recommend using a 32-bit operating system. The
memory you need is based on your operating system. Ensure that you have
enough memory so that no swapping takes place while running a test.

The table below shows some guidelines in determining the best CPU for
different network speeds.
Throughput
Recommended computer
less than 100 Mbs
PCI-based machine with a 32-bit

operating system
100 Mbs
Pentium 166 or greater with multiple

pairs (24 recommended) 1
100 - 155 Mbs
Pentium II or Pentium Pro 200 (or

greater)
over 155 Mbs
Multiple Pentium II or Pentium Pro

200 endpoints
With a TcpWindowSize setting of 64586.
We saw an 18% improvement when we modified this value in the windows

registry.
Refer to the Windows NT Resource Kit on the Microsoft Developer Network
for more information. Calculating Memory Requirements Chariot endpoints are
designed to run in any machine with enough memory to sufficiently run the
operating system. If you plan to use multiple pairs on a single machine, you may
want to calculate the number of pairs that will run without causing the operating
system to swap either code or data.
The table below can be used to plan this number of pairs. The Base RAM
column indicates the amount of memory that is allocated by the endpoint before
running any pairs. If the endpoint is not being used, this amount may go towards
zero if the operating system supports swapping. The protocol columns indicate
the amount of memory required for a pair of that protocol.
Base
Operating RAM
TCP
UDP
SPX
IPX
APPC
System
(in KB/pair KB/pair KB/pair KB/pair KB/pair
KB)
Windows
NT 4.0
2,076 35 - 60
160 180
35 - 60
160 180
55 - 85
Windows
95
1,100 40 - 65
100 145
40 - 65
55 - 75
N/A
OS/2
1,096 50 - 65
150 170
315 340
150 170
65 - 90
NetWare
1,100 80 - 110
320 340
70 - 100
260 280
N/A
Windows
3.1
550
72 - 600
72 - 600
N/A
N/A
N/A
UNIX
1,260
680 1,100
688 1,250
N/A
N/A
N/A
MVS
666
25 - 48
24 - 52
N/A
N/A
22 - 44
Base
Operating RAM
TCP
UDP
SPX
IPX
APPC
System
(in KB/pair KB/pair KB/pair KB/pair KB/pair
KB)
Windows
NT 4.0
2,076 35 - 60
160 180
35 - 60
160 180
55 - 85
Windows
95
1,100 40 - 65
100 145
40 - 65
55 - 75
N/A
OS/2
1,096 50 - 65
150 170
315 340
150 170
65 - 90
NetWare
1,100 80 - 110
320 340
70 - 100
260 280
N/A
Windows
3.1
550
72 - 600
72 - 600
N/A
N/A
N/A
UNIX
1,260
680 1,100
688 1,250
N/A
N/A
N/A
MVS
666
25 - 48
24 - 52
N/A
N/A
22 - 44
These RAM usage numbers represent sending with "send_datatype = ZEROS".

Other send_datatypes require memory buffers roughly equivalent to the disk
size of the .CMP file being used. Add 2KBytes when using send_datatype =
NOCOMPRESS.
Capacities
The table below shows some example pair capacities we have tested on various
computers. These pairs ran on a 10Mb Ethernet LAN. The number in the pairs
column represents the number of pairs this machine supported as Endpoint 2 for
a single test. We used the default values for all tests. An exception: for datagram
testing, we lengthened the time-out values as well as the initial delay in the tests.
Operating
TCP UDP SPX IPX APPC
Computer RAM
System
pairs pairs pairs pairs pairs
Windows
NT 4.0
Dell P166
32 M
500
100
300
100
200 1
Windows
95 2
Dell P133
16 M
18
100
40
175
N/A
OS/2 4.0 3
Dell P166
32 M
500
200
20
20
500
NetWare
4.12
Dell P100
64 M
500
200
100
100
N/A
Windows
3.x
Compaq
8M
N/A
N/A
N/A
AIX 4.1
IBM
Power PC
604
133Mhz
64 M
200
180
N/A
N/A
N/A
This test ran on the Microsoft SNA Server

2 with Novell Client32
3 with Novell Client for OS/2
NOTE: This table does not represent the full capacities of these operating
systems and stacks. They merely represent some of the larger tests that we have
run in our test lab.
CPU Utilization
What effect does running Chariot endpoint have on the other applications you
may be running on your desktop? This depends upon the Chariot tasking
structure for the particular endpoint platform.
For Windows 95, Windows NT , OS/2, and NetWare, the Chariot tasks
run under a single process as threads.
For UNIX, the Chariot tasks run as separate threads.
For Windows 3.x, there is one single process/thread for the endpoint.
All Chariot tasks run at normal priority, meaning they compete for CPU cycles
on an equal basis with most applications. A base endpoint runs between 2 - 14
tasks in idle state (depending on what protocols are installed), and creates an
additional task per endpoint pair. Although it depends on machine capacity and
applications, you can normally expect to run up to 20 pairs before you will
notice degradation of such applications as spreadsheets or word processors.
Ganymede and Chariot are registered trademarks of Ganymede Software Inc.
Other names are trademarks of their owners.
APPC Performance with MVS/VTAM

Our MVS endpoint has been tested in a wide variety of environments-and we've
seen a wide range of throughput and response time values. Here's what we've
learned about what to expect with APPC and how to tune for improved
performance.
APPC Performance Expectations
This section discusses the performance you can expect, depending on the CPU
usage and speed, the type of channel-connected device, and the speed of the
partner endpoint hardware and software. (In the numbers cited below, a
lowercase "b" stands for bits, while an uppercase "B" stands for bytes.)
CPU Usage and Speed
We don't have precise numbers here, because there are so many variables. The
CPU speed and the percentage of its consumption can make a big difference in
the performance values you see.
A P/390 (PC Server 500 System/390, with 128 MB RAM) appears to be
very underpowered, when trying to get high APPC throughput numbers.
The best we've seen is 3.8 Mbps, which can be bested by almost any
Pentium PC.
With a 300 MIPs computer and a good channel attachment (discussed
below), we've seen 12 MBps (96 Mbps).
We strive for as little CPU overhead as possible in all of our endpoints. An idle
MVS endpoint consumes 0.0% CPU usage. However, CPU usage can reach
100% when running an intense Chariot test. We've seen that the majority of the
CPU usage is in the protocol stack. It's obviously difficult to improve your
performance once you're using 100% of the CPU's resources. So think through
what you want to accomplish with a given computer and make sure it's tuned
appropriately.
MVS Channel Attachments
We've received excellent feedback from IBM and Cisco on the throughput that
is possible through several of their APPC channel-attached products.
MVS/VTAM-Escon channel-MVS/VTAM
Expect up to 12 MBps (96 Mbps)
This number was obtained with one significant piece of VTAM tuning.
Both VTAMs default to using HPR, with its slow-start algorithm. Each
starts with a low effective bandwidth value, expecting the partner to bump
it up-but neither does. Thus, by default, throughput starts out low (8
Kbps) and stays there. For best performance, set the "capacity" parameter
in the major node definition to its maximum value (1,000 Mbps). HPR
still starts at 1/10th of that value, but increases it over time. The algorithm
can take more than 20 minutes of constant traffic to increase from 10
MBps to 12 MBps.
MVS/VTAM-Escon channel-IBM 3745-LAN
We understand that the 3745 family has an internal bus based on 16 Mbps
token-ring technology, limiting the throughput through these devices.
We understand that the bus technology in the 3172 (which is a modified
PC) limits its throughput. For best performance, we recommend a
high-end member of the Pentium family and the fastest bus and NICs
available.
Expect 10 MBps (or more)
We understand that the improved bus architecture of the 2216 family
offers excellent throughput. With the proper use of chaining, large RU
sizes, and Multi-Path Channel (MPC) in combination with the High
Performance Data Transfer (HPDT) options, throughput of up to 15
MBps is possible.
MVS/VTAM-Escon channel-Cisco 75xx CIP Router-LAN
Expect 10 MBps (or more)

Tests with high-end models of Cisco's CIP Router have shown throughput
of 10 MBps. This was achieved with VTAM 4.4 storage pre-allocation
and tuning of the MVS dispatch priority (as discussed below).
The vendors have published good information on mainframe performance
expectations. See http://www.cisco.com/warp/public/731/data/dcr_wp.htm for
Cisco's performance comparisons between its 7500 CIP Router family and
IBM's 2216 (covering both APPC and TCP/IP). See
http://www.networking.ibm.com/vta/vtafpa3.html for IBM's performance
comparison of 3745/3746 controllers and Cisco CIP Routers (using VTAM
version 4.3).
Performance of Partner Endpoints
We offer APPC support today on our OS/2, Windows 95/98, Windows NT, and
MVS endpoints. When one endpoint is MVS, the hardware and APPC software
the partner endpoint uses can greatly affect the throughput you see.
OS/2 products
Use IBM's latest software, Communications Server/2 version 5.0 or 4.1
when testing APPC performance. Compared to the IBM's older
Communications Manager/2 version 1.11, throughput has been
significantly improved.
Windows NT, 95, and 98 products
In our internal APPC peer-to-peer testing, we've seen IBM's two APPC
products (Communications Server/NT and PCOMM for Windows NT)
offer throughput up to three times greater than Microsoft's SNA Server
for Windows NT v4.0 or v3.0.
Avoid using version 4.1 of IBM's PCOMM for Windows NT or Windows
95 when connecting with APPC to MVS. Their default DLC Windows
Size is too small for MVS and cannot be changed-throughput is about
1/10th of expectations. This is fixed in PCOMM version 4.2.
In Microsoft's testing using SNA Server as a gateway (thus, not as an
endpoint), they report throughput and capacity much greater than IBM's
Communications Server/NT (see

http://www.microsoft.com/sna/Comparisons/compet.asp for more
information).
We recommend careful evaluation of these products. In configurations
representative of your environment, performance can vary dramatically. All of
these products benefit from fast CPUs and lots of RAM.
Some Guidelines for Tuning APPC Performance for MVS/VTAM
Depending on what you're trying to measure, you will want to consider to
following tuning guidelines.
Dispatch priority in MVS
We recommend setting the dispatch priority for the MVS endpoint to one
level lower than your real-time production applications, such as CICS,
IMS, and DB/2. In turn, these applications have generally been set at one
level lower than VTAM's priority.
Using High-Performance Routing (HPR)
We have seen that using HPR for local peer connections sometimes gives
lower performance than with classic APPN. However, IBM has continued
to improve its HPR software. So we strongly recommend testing your
current APPC software both with HPR disabled and enabled.
The available-bit-rate settings may have some anomalies when connecting
from VTAM to VTAM, depending on the VTAM levels. See the
discussion above of MVS channel attachments.
Connection networks vs. network nodes
Always use connection networks for sessions with APPC systems on the
same LAN. When using APPN, connection networks give you a direct
connection between LUs; without a connection network definition, the
APPN default is to route all traffic through a network node, which results
in at least one extra hop for all APPC traffic.
DLC Window Sizes
The MAXOUT value of the partner's DLC Window Size needs to match
that used by MVS/VTAM. We recommend a MAXOUT value of 4.
The DLC Window Size is readily settable on IBM's Communications

Server/2 for OS/2. The default value for IBM's Communications Server
for Windows NT version 1.0 is too low, resulting in poor performance. It
can be changed in the ASCII text configuration file.
This default value is also too low, and not settable, in IBM's PCOMM
version 4.1 products-look for a settable value in version 4.2.
New Changes in VTAM version 4.4
Much of IBM's work in VTAM version 4.4 is a performance rewrite. IBM
extensively reworked the APIs and storage management for performance. See
IBM's website for information on performance improvements in VTAM version
4.4.
IBM's APING program is an internal application in VTAM version 4.4. That
means that it takes less overhead than before-avoiding LU 6.2 API crossings and
security, for example. Whereas APING and our software gave comparable
performance numbers in previous VTAM releases, expect improved
performance numbers with the new APING. These are a little unrealistic,
though, since they can't be attained by real VTAM applications.
The MVS endpoint provides the same performance results seen by real
applications.
Storage handling and pre-allocation (with VTAM 4.4)
To take advantage of the improved storage handling in VTAM 4.4, we suggest
an initial Communications Storage Manager (CSM) setting of 4 MBytes.
Emulating Multiple Users

A single Chariot pair connection can represent the traffic generated by many
users of a given network application. The values in the Chariot application
scripts default to, in effect 'drive this traffic as fast as is possible.' This is in fact
far more than any single end user can generate.
A concrete example will help. For a simple case, look at the Chariot script
FILESNDS.SCR. This script represents a client machine connecting to a file
server, transferring a file to the server, and receiving an application level
acknowledgement that the transaction is complete. The defaults involve a
100kByte file size, and the file transfer repeats 100 times, each new transfer
happening immediately after the conclusion of the last. On 10Mbps Ethernet,
this takes about 10 seconds. The most active power user on a given network
does not do 100 file transfers every 10 seconds! It is impossible for a person to
hit the keys fast enough to accomplish this. So the trick with Chariot is actually
to slow things down.
There is a variable in all of the Chariot application scripts, the
"transaction_delay." The transaction delay variable sets the time between
repetitions of the scripted transaction. The default is to immediately repeat the
scripted transaction until the script completes. This is fine for testing that
transaction's behavior on a given network, but it is considerably more traffic
than a normal user generates. The question is, 'How much traffic does a normal
user generate?" For now, we'll confine ourselves to a single application. For
example purposes, we will stick with our file transfer script, FILESNDS.SCR.
We will have to engage in some educated guesswork, or use a protocol analyzer
to track discrete uses of an application during the day, or perhaps follow an
average end user around for a day. So, as an example, we might determine that
our typical end user transfers a file to the file server about every 20 minutes. So
for the average user, there is an average delay between transactions of 20
minutes. The variable 'transaction_delay' available in the script accepts values in
milliseconds. 20 minutes is 1,200 seconds and 1,200,000 milliseconds. If we
enter a delay time between transactions of 1200000 (do not use commas when
entering values in Chariot scripts), we will slow Chariot down to where it is
generating the typical file transfer traffic of a single user.
What about representing multiple users? If we have created the traffic level of
one typical user, then 10 times as much traffic would be the traffic generated by
10 users. Reduce the transaction delay by a factor of 10, to 120,000 milliseconds
(every 2 minutes), and we have 10 user's traffic. Reduce the transaction delay by
a factor of 100, to 12,000 milliseconds (every 12 seconds), and we are
representing 100 people.
How far can we go with this process? That depends on your situation. The
mathematical limit of the reasoning process we have gone though breaks down
when the delay time is not significantly larger than the response time of a given
script. To find out the limit in your network's circumstances, run a quick test,
having made any changes you need to for other modeling purposes, but with
'transaction_delay' set to zero. Look at the resulting response time. This value is
the lower limit to consider in our modeling process. If the transaction delay is
less than the response time, then the next transaction will need to start before the
last one ends, and that is not going to happen. In the example we have been
using, FILSENDS.SCR always has a relatively high response time, and on 10
megabit Ethernet, going through one hub only, the response time for that script
is about 105 ms on average, maximum response time about 140 ms. Under such
circumstances, 500 ms is probably about as low as we would want to go. So our
limit as to the number of users we can represent is 1,200,000ms/500ms = 2400
end users (doing file sends). Notice that we can actually represent more users on
a faster data link technology. ATM or Fast Ethernet would give us a lower
response time, and we could probably represent more users by a factor of about
100 (240,000 users). Also, if the script we were using was a shorter transaction,
but still had the same typical amount of time between transactions, then we
would also have a lower response time, and could represent more users. If
however, we used larger file sizes, one Meg perhaps, rather than the default
sizes of 100,000 kB, then we would have to reduce the number of users we can
represent.
Now that's the mathematical limit of this model. Is its practical limit that high?
Well, with Chariot, the limit really depends on what one is trying to accomplish.
Some deep thought concerning just what is under test and whether the test being
applied is reasonable is always warranted. There are also additional factors to
keep in mind. Calls to the system clocks work differently on different operating
systems, so OS/2, Windows 3.1 and NetWare should not be used for delay times
below 1 second. When using our benchmarking class of scripts, always use the
'short connection' scripts rather than the 'long connection' ones (FILESNDS, not
FILESENDL). This is because one wants to include the overhead of set up and
teardown of connections. The specific application emulation scripts generally
already account for this distinction. This traffic representation is also very
'bursty,' with long periods of no traffic being generated, and then brief periods of
full activity. This is how traffic in the 'real world' works, and it is specifically to
emulate such traffic that Chariot was designed.
There is room to refine our model further. The option exists in Chariot's
application scripts to randomize the sleep times, of which 'transaction_delay' is
one. Rather than leaving our delay's at a set time, we can randomize them over a
range of values. So rather than a 20 minute delay, we could give it a range of
15-25 minutes, or perhaps 0-40 minutes. We would change the radio button in
the 'Edit a sleep variable - transaction_delay' window to uniform distribution,
and set each boundary limit. For example, 900000 for 15 minutes, 1500000 for
25 minutes, etc.
The most important factor we haven't yet accounted for is the possibility of two
systems attempting to use the network at the same time. The model we have
developed so far uses a single connection at a time. It can emulate thousands of
users over a period of time, but it cannot emulate more than one user at
EXACTLY the same time. There is never any contention for bandwidth. The
solution to this is to divide the number of users among several pairs, preferably
among several machines. If several machines are available for testing, with even
numbers on each end of a network cloud, one can divide the number of users
one wishes to emulate among several endpoint connection pairs, and spread
those among different pairs of machines. Additionally, if multiple network cards
(or multiport cards) are available, the connections to a given machine can be
divided among them. If we wish to take into account contention for network
bandwidth, the question to consider is, 'how many connections must potentially
happen at the exact same time?' The answer to that is also the minimum number
of pairs that must be used to represent that application's traffic. A caveat to this
is, if the testing need is to maintain the number of simultaneous connections a
piece of equipment is capable of, the number of connection pairs should match
that value, and there should no delay between transactions.
So the two theoretical factors to account for are 'How many users to represent?'
and 'How many can be connected at precisely the same time?' However, the
more practical factor to start with is, 'How much equipment is available to work
with?' Determine how many machines, and how many network ports, are
available, and then decide how many pairs to use, and how much traffic each
pair should drive. Keep in mind that 1000 users are better represented by several
pairs spread over several machines than by one pair from one machine.
For further discussion, see the Testing Tip, "Representing and Entire Network's
Traffic with Chariot."
Ganymede: Pegasus Technical Support
Pegasus Technical Support

third-party software and download documentation for Pegasus.
http://www.ganymede.com/support/pegasus/index.phtml (1 of 2) [3/14/2000 8:22:10 AM]
Ganymede: Pegasus Technical Support
http://www.ganymede.com/support/pegasus/index.phtml (2 of 2) [3/14/2000 8:22:10 AM]
Ganymede: Pegasus Service Updates

Pegasus Performance Enhancement Patch
Ganymede Software is releasing a performance enhancement patch for version
1.1 of Pegasus. This patch is designed to increase the efficiency of the Pegasus
server when 500 (or more) connections are configured and those connections are
executing application scripts at fifteen minute intervals (or more frequently).
Installing this patch will improve performance when the Pegasus server is
accumulating and processing a high volume of data. Users with fewer
connections and less frequent test schedules may want to apply the patch,
though the performance enhancing effects may be less immediately visible. For
http://www.ganymede.com/support/pegasus/pegasus_updates.phtml (1 of 2) [3/14/2000 8:22:13 AM]
Ganymede: Pegasus Service Updates
details and downloading instructions, see the README file.

Click here to view or print the README file.
http://www.ganymede.com/support/pegasus/pegasus_updates.phtml (2 of 2) [3/14/2000 8:22:13 AM]
Ganymede: Pegasus FAQ
Pegasus FAQ
What are the minimal hardware and software requirements I need to install
Pegasus?
How do I create a dedicated user account with the Windows NT User Manager?
How do I add Pegasus Administrators and Pegasus Operators with the Windows
NT User Manager?
Specific issues related to Crystal Reports and Pegasus Reports
Importing Scripts
http://www.ganymede.com/support/pegasus/pegasus_faq.phtml (1 of 19) [3/14/2000 8:22:40 AM]
Multimedia and ATM Support in Pegasus

Working with Endpoints and Connections
What are the minimal hardware and software requirements I need to
install Pegasus?
The following chart indicates the recommended minimal hardware
specifications of the computer where you plan to install and run the Pegasus
server. The installation program automatically enforces minimal RAM and hard
disk space requirements. Minimal CPU speed is not automatically enforced.
Although any Pentium processor is effective enough to run an eval copy of
Pegasus, we recommend you upgrade to the respective processors listed in the
chart before installing and running a retail version of Pegasus.
Number of
Connections
CPU
RAM
Hard Disk
Space
10 Connections
300 MHz
Pentium II
128 MB 1.0 Gbytes
50 Connections
300 MHz
Pentium II
128 MB 1.0 Gbytes
200 Connections
300 MHz
Pentium II
128 MB 1.5 Gbytes
500 Connections
400 MHz
Pentium II
256 MB 2.0 Gbytes
1000 Connections
450 MHz
Pentium II
4.0 Gbytes
384 MB Multiple SCSI
RAID 0 or 1
4.0 Gbytes
512 MB Multiple SCSI
RAID 0 or 1
2000 Connections
450 MHz
Pentium II
5000 Connections
4 Processor
450MHZ Pentium 1 GB
II
16.0 Gbytes
Multiple SCSI
RAID 0 or 1
Before installing Pegasus 1.2, always install software packages in the following
order:
1. MS Windows NT 4 Workstation or Server
2. MS Peer Web Server (or IIS 3, or IIS4)
3. Windows NT Service Pack 3 or Service Pack 4
4. MS Internet Explorer 4.01 (or Netscape 4.06)
After creating a dedicated user account in the Windows NT User Manager,
install the Pegasus server. See the "Installing Pegasus" chapter in the Pegasus
1.2 User Guide for more important information on installing the prerequisite
software.
How do I create a dedicated user account with the Windows NT User

Manager?
You need to create a dedicated user account on the Windows NT computer
where you're installing the Pegasus server. We recommend you assign this
account the username 'Pegasus' as this will make it easy to distinguish if your
list of users grows significantly. Throughout this section, we refer to this new
account as the Pegasus user account. During Pegasus installation, you will enter
this account information in the Set Up a Dedicated Account dialog. Pegasus uses
this new account information for two purposes: to run the Windows NT services
associated with Pegasus, and to access the default printer when printing
automatically-generated reports.
The new account must have the following properties:

It must be part of the "Administrators" or "Power Users" group at the
Pegasus server computer.
It must have a password that does not expire.If your domain does not
allow users to select the password never expires option, or if
you ever need to change this password, you must first stop the Pegasus
Server service, change its logon password, change the password on the
domain controller, and then start the Pegasus Server service. See
"Changing Your Network Domain Password" for details.
It must have a default printer defined, if you plan to print

automatically-generated reports.
To create a new user account which has these properties using the Windows NT
User Manager:
1. Select Start\Programs\Administrative Tools\User Manager. A dialog
like the following is shown.
2. From the User menu, select "New User..." Fill in the fields in the dialog
as shown below (you may select any Password). Make sure you check the
Password Never Expires checkbox.
We recommend you make the Pegasus user account a member of an

existing domain in your network For information on how to do this, see
"Making the Pegasus user account a Member of the Network's
Domain". If you cannot (or choose not) to make the Pegasus user
account a domain user, see "Making the Pegasus user account a Local
User of the Pegasus Server Computer" for instructions.
3. When you have filled in all the fields, press the Groups button in the
lower left corner of the dialog. The Group Memberships dialog is shown.
4. Add the Pegasus user account to the Administrators group by

highlighting Administrators in the Not Member of: box and pressing the
-Add button. The
icon for the Administrators group is now shown in the "Member of:" box:
5. Press OK to close this dialog, then press OK again to save the account
information for the Pegasus user account in the User Manager. The User
Manager dialogshould now look like this:
Making the Pegasus user account a Member of the Network's Domain

We recommend that the Pegasus user account be established as a member of an
existing domain in your network. This enables easy access to network printers,
which you may use to
print Pegasus reports. There are three steps involved in adding the 'Pegasus' user
to the domain:
1. When creating the new account in the Windows NT User Manager, in the
Username field, enter a "Domain\Username" using your network's
domain and the username you want to establish for the account
(Olympus\Pegasus, for example).
2. Add the Pegasus user account to your network's domain and ensure that
the account has all necessary privileges. You may need to work with your
network domain administrator to create the new account, so that the user
is known across the domain and can access network-attached printers. If

you are installing the Pegasus server on a Windows NT Workstation, the
User Manager for Domains application which enables you to add new
users to your network's domain, is not locally available. This application
is only installed on Windows NT Servers.
3. Specify a default printer for the new account. In order to print Pegasus
reports,the 'Pegasus' account must be associated with a default printer.
1. Log on to the Pegasus server computer using the Pegasus user
account
2. From the Start menu, select Settings\Printers
3. Highlight the printer you want to establish as the default printer for
printing Pegasus reports (if you are changing the default printer,
this will affect all printing tasks, not just Pegasus reports).
4. If the printer you want is not shown, click the Add Printer icon and
follow the instructions to add the desired printer to the list of
available printers.
5. From the File menu, select "Set as Default". A checkmark is shown
to indicate the selected printer has been established as the default
printer for the Pegasus user account. You can return to this dialog
and change the default printer at any time.
Changing Your Network Domain Password
If you ever change your network domain password, the next time the computer
is shut down and restarted the Pegasus Server service in Windows NT cannot
start. After changing your network domain password, follow these steps to avoid
an unintended failure of the Pegasus Server service:
1. Select Start\Settings\Control Panel and double-click on the Services
icon.
2. Select the "Pegasus Server" service and press Startup
3. In the Service dialog, in the Log On As This Account, enter and confirm
your new NT password.
When you change your network domain password, Pegasus continues to run
with your old password until the Pegasus server computer is stopped and
restarted. Until then, you will be able to log in with both your old and your new
passwords. For this reason, we recommend that you shut down and restart the
Pegasus server computer whenever you change your password.
Making the Pegasus user account a Local User of the Pegasus Server
Computer
If the Pegasus server computer is not in a domain environment (if, for example,
it resides in a UNIX environment or is part of a workgroup instead of a domain),
you must establish the Pegasus user account as a local user of that computer. In
addition, you may prefer this option if there is a locally-attached printer and you
have no need to access a network printer to print Pegasus reports.
To make the Pegasus user account a local user, do not specify a domain name in
the Userame field when creating the new account in the User Manager:
1. Select Start\Programs\Administrative Tools\User Manager.
2. From the User menu, select "New User..."
3. In the Username field, enter the username you want to establish for the
account using the format username(enter Dan's_Desktop as the username,
for example).
If you plan to print Pegasus reports, you must specify a default printer (see step
3 in "Making the Pegasus user account a Member of the Network's Domain").
This must be a locally-attached printer or a network printer that supports LPD
printing via the Microsoft TCP/IP Printing Service (consult your Windows NT
manual for details on adding and using this service).
How do I add Pegasus Administrators and Pegasus Operators with the

Windows NT User Manager?
This section walks you through the steps you need to take to add users to the
Pegasus Operators and Pegasus Administrators groups with the User Manager. It
begins by providing some background to help you understand how user
privileges are defined in Pegasus, and how Pegasus security works to limit
access to Pegasus features and functions.
Understanding User Privileges in Pegasus

Pegasus has three levels of user privileges. These limit access to the functions
on the Pegasus server.
1. "Pegasus Operators" can view and print automatically-generated reports,
as well as access connection analysis functions from the Pegasus Home
Page.
2. "Pegasus Administrators" can perform all operations associated with the
Pegasus server, including configuration.
3. All other users can view automatically-generated reports with their Web
browsers.
A good rule of thumb is that personnel who need to configure Pegasus should be
added to the Pegasus Administrators group. Personnel on the help-desk staff or
personnel who perform network troubleshooting should be added to the Pegasus
Operators group. However, in order to best determine which personnel belong in
each group, you need to know a little more about how Pegasus security works to
allow and prohibit access to the different levels of Pegasus functions.
Accessing Pegasus Features and Functions
Users access Pegasus features and functions via two separate interfaces: the
Pegasus Configuration application, and the Pegasus Home Page.
The Pegasus Configuration application, a program accessed via the Windows
NT Start menu, is where the bulk of the work involved in configuring,
administering, and managing the Pegasus server and Pegasus objects (such as
endpoints, connections, and reports) is done.
The Pegasus Home Page, viewed via a Web browser, is where users can access
the bulk of the Pegasus server's output. The Pegasus Home Page consists of
three buttons (View Reports, Analyze Connections, and Administer Pegasus)
which let users access three different levels of Pegasus functions.
Pegasus security is designed to let all users view the valuable information
contained in the automatically-generated Pegasus reports. It lets you grant a
narrower pool of users the ability to analyze detailed information about specific
connections. It then lets you specify one small group of users who can access the
territory where system-level configuration details are displayed and changes are
made that affect the Pegasus server's infrastructure.
Pegasus Security Checkpoints
Pegasus security works via a system of three user authentication checkpoints,
triggered when the user attempts to execute the following commands:
1. Invoking Pegasus Configuration.
2. Pressing the Analyze Connections button on the Pegasus Home Page.
3. Pressing the Administer Pegasus button on the Pegasus Home Page.
At each checkpoint, Pegasus displays a Sign On dialog prompting you to enter a
valid domain\user name and password. To pass the checkpoints (and access the
associated features and functions) depends on whether the user is a member of
the Pegasus Operators group, the Pegasus Administrators group, or is a general
user not assigned to either group:
General users not assigned to either group cannot pass any security
checkpoints.
Authorized Pegasus Operators can pass only one security checkpoint:
pressing the Analyze Connections button.
Authorized Pegasus Administrators can pass all three security
checkpoints.
Configuring 'User Rights' for Pegasus Operators and Pegasus
Administrators
Users added to the Pegasus Operators and Pegasus Administrators groups must
have both of the following "User Rights:"
Log on locally
Access this computer from the network
To ensure that the users being added to these two groups have the appropriate
rights, take the following steps at the Windows NT User Manager:
1. Select Policies\User Rights
2. From the "Right:" pulldown select "Access this computer from network"
3. Press the Add button

4. From the "List Names From:" pulldown, select the name of the Pegasus
server computer
5. Select "Pegasus Administrators" from the "Names" list, and press the Add
button
6. Select "Pegasus Operators" from the "Names" list, and press the Add
button
7. Press the OK button
8. Select "Log on locally" from the "Right: pulldown, and repeat steps 3
through 7
9. Press OK to close the User Rights Policy dialog
Adding Users to Groups in the User Manager
To add users to the Pegasus Administrators and/or Pegasus Operators groups,
and grant them the associated access privileges, take the following steps at the
Windows NT User Manager:
1. Highlight "Pegasus Administrators" (or "Pegasus Operators") from the list
of Groups in the bottom frame of the User Manager
2. From the User menu, select Properties
3. The "Local Group Properties" dialog is shown. Press the Add button
4. The "Add Users and Groups" dialog is shown. From the "List Names
From:" pulldown, select either the network domain name (to display a list
of all users in the
domain) or the name of the Pegasus server computer (to display a list of
all local users)
5. In the "Names" list, highlight a username and press the Add button
6. Repeat steps 4 and 5 to add more users to the selected group
7. Press the OK button to close the "Add Users and Groups" dialog
8. Press the OK button to close the "Local Group Properties" dialog
When you are finished adding Pegasus Operators and Pegasus Administrators in
the User Manager, close the User Manager window. If you performed this step
during the installation of the Pegasus server, when you close the User Manager
window the installation program recommences (see page 39 in the Pegasus 1.2
User Guide for information on what happens during the rest of Pegasus
installation).
Specific issues related to Crystal Reports and Pegasus Reports

Can I install the Pegasus server on a computer that already has Crystal
Reports installed?
The Pegasus server should be installed on a dedicated, clean computer. If you
attempt to install the Pegasus server on a computer which already has Seagate
Crystal Reports installed, the Pegasus installation program prompts you to
uninstall Crystal Reports.
There may be situations where you cannot install the Pegasus server on a
dedicated computer. If you are installing the Pegasus server on a computer
where Crystal Reports is already installed, and you do not want to uninstall
Crystal Reports, you must first verify that the versions of Crystal Reports and
Microsoft Access currently installed on the computer are the same versions used
by Pegasus 1.2. Pegasus does not support any other versions of these
applications.
Pegasus only runs reliably with the following versions of Crystal Reports and
Microsoft Access:
Crystal Reports Designer version 6.0.1.151
Crystal Reports Dictionary Designer version 6.0.0.31
MS Access version 7.0
If you have these exact versions already installed, you can install the Pegasus
server on the same computer without encountering problems. When the Pegasus
installation program prompts you to uninstall Crystal Reports, press the Yes
button. You are prompted to insert the original Crystal Reports CD (Pegasus
cannot uninstall Crystal Reports without the original CD). Press the Cancel
button, and Pegasus completes its installation successfully without uninstalling
Crystal Reports. Your existing reports continue to function normally.

Can I install Crystal Reports on a computer that already has Pegasus 1.2
installed?
No. You should not install Crystal Reports on a computer where Pegasus 1.2 is
already installed. If Crystal Reports is installed after Pegasus installation, some
of the Pegasus Web server registry settings will be altered by default. This can
cause errors and unpredictable behavior in the Pegasus server. These problems
occur even if you install the same version of Crystal Reports. To avoid
encountering errors, we recommend you DO NOT install Crystal Reports after
installing the Pegasus server.
What will happen to the Crystal Reports I've already defined on my
computer after I install Pegasus?
Prior to installing the Pegasus server on a computer running Crystal Reports,
verify that you are using the same versions of Crystal Reports (namely, Crystal
Reports Designer version 6.0.1.151 and Crystal Reports Dictionary Designer
version 6.0.0.31) used by Pegasus 1.2. In addition, make sure Microsoft Access
version 7.0 is installed on this computer.
If you are using these exact versions, you should not encounter any problems
with pre-existing Crystal Reports after Pegasus installation.
Can I create new Pegasus Reports?
Yes. There are two ways to create customized Pegasus reports, assuming you
have third-party reporting software installed. You cannot, however, import
customized reports into the Pegasus Configuration application in version 1.2;
which means that customized reports cannot be automatically-generated
according to a pre-defined schedule.
You can export Pegasus data using a CSV file format (see page 121 of the
Pegasus 1.2 User Guide) and create new reports using most reporting
software.
You can access the Pegasus database via ODBC and use your reporting
software to create customized reports. This procedure is not described in
the documentation shipped with version 1.2. For instructions on how to
access the Pegasus database using ODBC, contact our customer care
team.
Importing Scripts
How do I import a script into Pegasus?
You can import application scripts into Pegasus from Chariot and from our Web
site (http://www.Ganymede.com/support). See page 148 of the Pegasus 1.2 User
Guide for instructions.
Can I import the new Chariot multimedia scripts (voice over IP, IP
Multicast, RealMedia, etc.) into Pegasus?
No. Pegasus 1.2 does not support the new Chariot multimedia scripts.
Why are the default loop variable values of the same script different in
Pegasus and Chariot?
If you use both Chariot and Pegasus, you may have noticed that many of our
application scripts are shipped with both products. You may also notice that the
loop variables in the same scripts are set to different values, depending on the
product.
In Chariot, a single test is often used to generate lots of traffic for the purpose of
stress-testing the network. To generate that traffic, the same transaction is
repeated many times by setting the transactions_per_record loop variable in the
application script to a high number. Incrementing the
number_of_timing_records loop variable of a Chariot script is also a good
strategy for a user who wants to run a single test and gather enough timing
records to calculate a meaningful average.
In Pegasus, application scripts are typically used to execute a single transaction
at regularly scheduled intervals rather than multiple transactions all at once. This
is because when the user's goal is to monitor network performance, it is more
useful to run one uniform transaction between the same computers periodically,
and then measure and compare the results over time. This is why the
number_of_timing_records and transactions_per_record loop variables are

preset at 1 in all application scripts installed with Pegasus.
What happens to the loop variable values when I import a Chariot script
into Pegasus?
When you import a Chariot script into Pegasus, the loop variable values are
preserved. You should always modify newly imported Chariot scripts to ensure
the number_of_timing_records and transactions_per_record loop variables are
set to "1".
In addition, you may want to tailor some or all of the other loop variable values
in imported Chariot scripts to better suit your specific needs in Pegasus.
Multimedia and ATM Support in Pegasus

Does Pegasus support Multimedia and ATM applications?
Version 1.2 of Pegasus does not currently support multimedia and ATM
applications.
Working with Endpoints and Connections

When adding connections, how do I know which endpoint should be E1
(endpoint 1) and which endpoint should be E2 (endpoint 2)?
Always designate the initiating (or client) computer as Endpoint 1 and the
responding (or server) computer as Endpoint 2. Pegasus bases its reports (as
well as several other important operations) on the assumption that Endpoint 1 is
the initiating computer in connections. For example, in a report that breaks
down response time by department, Pegasus will group a connection's
response-time measurements under Endpoint 1's department.
For more information on this topic, see the "Defining Connections Between
Endpoints" chapter in the Pegasus Planning Guide.
How often do endpoints send their results back to the Pegasus server?
Endpoints keep their own schedules when used with Pegasus. They execute
scripts the first time within a 30-minute window after being scheduled by the
Pegasus server, and then execute the scripts on schedule after that. Endpoint 1
holds its results and returns what it has to the Pegasus server every 30 minutes.
If the Pegasus server cannot be reached, Endpoint 1 continues to hold the results
(for up to two weeks) until it can reach the Pegasus server.
Why aren't my connections generating any results?
If you have configured connections but are not generating results, use the Verify
button to confirm that your endpoints and connections are correctly configured.
A couple of symptoms of this are: when viewing reports an empty page comes
up, or analyzing connections takes you to a page which says no connections are
eligile for analysis due to lack of results. You should also look at the Pegasus
error logs to see if there are errors recorded here such as connectivity losses that
may indicate that one of the endpoints was not operational during the time
period in question.
See "Connections Are Not Generating Results" on page 116 of the Pegasus 1.2
User Guide.
919-469-0997 (voice)
919-469-5553 (fax)
customer care team.
Ganymede: Pegasus Specifications
Pegasus Specifications
Pegasus Network Monitor System Requirements
recommended
Pegasus Console
http://www.ganymede.com/support/pegasus/pegasus_specs.phtml (1 of 3) [3/14/2000 8:22:43 AM]

Integration
MicroMuse NetCool, etc
Pegasus Application Monitor System Requirements
recommended
Pegasus Console
Integration
MicroMuse NetCool, etc.
Ganymede: Pegasus Documentation
Pegasus Documentation
Pegasus 2.1 User Guide (10/99)
Contains detailed information about installing and configuring the Pegasus
server, as well as comprehensive documentation of Pegasus 1.2 features and
functions.
Pegasus 2.1 User Guide (2.0 MB, 359 pages)

http://www.ganymede.com/support/pegasus/pegasus_docs.phtml (1 of 2) [3/14/2000 8:22:46 AM]
Ganymede: Pegasus Documentation

scripts.
Messages and Application Scripts Manual (797K, 216 pages)

http://www.ganymede.com/support/pegasus/pegasus_docs.phtml (2 of 2) [3/14/2000 8:22:46 AM]
Ganymede: Pegasus Third Party Updates
Pegasus Third Party Updates

systems necessary to run Pegasus.
Operating Systems
Windows NT
Windows 95
Windows 98
http://www.ganymede.com/support/pegasus/pegasus_third.phtml (1 of 2) [3/14/2000 8:22:49 AM]
Ganymede: Pegasus Third Party Updates
Browsers
Download Internet Explorer v4.01
Download Internet Explorer v4.01 Service Pack 1
Download Netscape Communicator v4.5
http://www.ganymede.com/support/pegasus/pegasus_third.phtml (2 of 2) [3/14/2000 8:22:49 AM]
Ganymede: Endpoint Technical Support
Endpoint Technical Support

third-party software and download documentation for Performance Endpoints.
http://www.ganymede.com/support/endpoints/index.phtml (1 of 2) [3/14/2000 8:22:51 AM]
Ganymede: Endpoint Technical Support
http://www.ganymede.com/support/endpoints/index.phtml (2 of 2) [3/14/2000 8:22:51 AM]
Ganymede: Endpoint Service Updates

Endpoint 3.x Windows 95 Installation Patch
This is not needed for Windows 98
Download and execute this file to unzip the missing MSVCRT.DLL file. Make
sure this file is copied to the \WINDOWS\SYSTEM directory.
Service Update for Version 3.1 of the MVS Endpoint

Fixed in endpoint versions after 3.1
This service update provides support for IBM TCP/IP Release 3.4, also known
as 'eNetwork Communications Server OS/390 R2.5'. This update is compatible
with all earlier releases of TCP/IP. You should also download this update if you
have received the following error messages:
CHR0208 Unknown UDP Communications Failure
CHR0154 Error was 36 on Call Connect
For details click here for the readme
http://www.ganymede.com/support/endpoints/endpoints_updates.phtml (1 of 2) [3/14/2000 8:22:54 AM]
Ganymede: Endpoint Service Updates
Service Update for Version 3.1 of the Windows NT Endpoint

Fixed in endpoint versions after 3.1
The service update program NTNPEFIX.EXE preempts a potential conflict
between our version 3.0 endpoint and the shared Microsoft C Runtime file
(MSVCRT.DLL).
For details click here for the readme
http://www.ganymede.com/support/endpoints/endpoints_updates.phtml (2 of 2) [3/14/2000 8:22:54 AM]
Ganymede: Endpoint FAQ
Endpoint FAQ
How do I set the MTU size for Windows 95, 98, NT, or 2000?
MVS: Timing records are not being returned when connecting to an MVS
endpoint.
NetWare: I'm running a UDP or IPX test with endpoint on NetWare 5 and
received message CHR0251, stating that a required NLM could not be loaded.
Windows: How do I manually uninstall a Windows 3.1, Windows 95/98, or
Windows NT/2000endpoint?
How do I set the MTU size for Windows 95, 98, NT, or 2000?
To configure MTU size for Windows, you have to set a registry variable.
For NT or 2000, open the registry (use REGEDT32) to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
http://www.ganymede.com/support/endpoints/endpoints_faq.phtml (1 of 6) [3/14/2000 8:22:58 AM]
\Services\"Adapter Name"\Parameters\Tcpip
Create a new variable of type REG_DWORD called MTU and enter the
number of bytes up to the MTU of the underlying network. For example:
Ethernet is 1500.
This information was obtained from the NT Resource Kit, which is

shipped as a part of the developer's assistance program.
For 95, open the Registry (use REGEDIT) to:
HKEY_LOCAL_MACHINE\System\CurrentControlSet
\Services\Class\NetTrans\
Figure out which 000n is the TCP/IP protocol for your connection by
looking at the other values, then open up that 000n. The parameter to look
for to make sure you have the right one is DriverDesc set to "TCP/IP".
Inside that 000n, create a new string variable called "MaxMTU" and enter
your value. 1500 is the default. This information was obtained from
"Windows 95 Networking FAQ" maintained by Richard Graves.
For 98, open the Registry (use REGEDIT) to:
HKEY_LOCAL_MACHINE\System\CurrentControlSet
\Services\Class\NetTrans\
Figure out which 000n is the TCP/IP protocol for your connection by
looking at the other values, then open up that 000n. The parameters to
look for to make sure you have the right one are DriverDesc set to
"TCP/IP" and IPAddress set to your computer's IP address. Inside that
000n, create a new string variable called "MaxMTU" and enter your
value. 1500 is the default. This information was obtained from "Windows
95 Networking FAQ" maintained by Richard Graves.
MVS: Timing records are not being returned when connecting to an MVS
endpoint.
The MTU size in your TCP/IP setup may be incorrect. To fix the problem, edit
the TCP/IP profile member. For OS390 V2R5 this member is named
TCPIP.PROFILE.TCIP. This member contains the TCP/IP profile statements
for GATEWAY and BSDROUTING PARMS.
Under the heading GATEWAY look for a statement similar to the following:
44.0 = ETH1 1500 0 255.255.0 0.44.44.0
Change the value 1500 to 1492.
Under the heading BSDROUTING PARMS look for a statement similar to the
statement above and change the value 1500 to 1492.
NetWare: I'm running a UDP or IPX test with endpoint on NetWare 5 and
received message CHR0251, stating that a required NLM could not be
loaded.
Press OK on the message box and re-run the test. The NLM should now be
recognized as loaded, and you should not receive the message again.
Windows: How do I manually uninstall a Windows 3.1, Windows 95/98, or

Windows NT/2000endpoint?
There may be situations when you run into problems during the uninstall
process and need to manually remove one of these endpoints. The exact
instructions vary by operating system, but the main actions are to stop the
endpoint, to remove the program, and to clean up the configuration files.
For Windows NT and 2000:
1. From the Start menu, select Settings and then Control Panel.
2. Double-click on the Services icon.
3. Highlight Ganymede Software Endpoint.
4. Press the Stop button.
5. At a command prompt, enter the following (assuming the endpoint is

installed in d:\Ganymede\Endpoint.):
d:
cd \GANYMEDE
del /Q /S ENDPOINT
rmdir /Q /S ENDPOINT
6. Start REGEDIT to edit the Windows Registry.
7. Open:
HKEY_LOCAL_MACHINE\SOFTWARE\GANYMEDE
8. Highlight the Endpoint folder and press the Delete key.
9. Open:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Windows\CurrentVersion\Uninstall
11. Open:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
For Windows 95 and 98:
1. From the Start menu, select Settings and then Control Panel.
2. Double-click on the Services icon.
3. Highlight Ganymede Software Endpoint.
4. Press the Stop button.
5. At a command prompt, enter the following (assuming the endpoint is
installed in d:\Ganymede\Endpoint.):
d:
cd \GANYMEDE
deltree /Y ENDPOINT
6. Start REGEDIT to edit the Windows Registry.

7. Open:
HKEY_LOCAL_MACHINE\SOFTWARE\GANYMEDE
9. Open:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Windows\CurrentVersion\Uninstall
11. Open:
For Windows 3.1:
1. Close the application named "Windows 3.1 Ganymede Software
Endpoint."
2. From an MS-DOS prompt, enter the following (assuming the endpoint is
installed in d:\Ganymede\Endpoint):
d:
cd \Ganymede
deltree /Y Endpoint
3. Edit the WIN.INI file in your Windows directory to remove from the
Windows section the line load=D:\Ganymede\Endpoint\endpoint.exe
919-469-0997 (voice)
919-469-5553 (fax)
customer care team.
Ganymede: Endpoint Specifications
Endpoint Specifications
Here is the hardware and software with which we have tested endpoints. If you have questions about a product not
listed here, please contact us at info@ganymede.com.
Endpoints run as an application on the communication stack. Thus, it can run over any DLC that is supported by
the stack you are using. The hardware requirements for endpoints depend on the operating systems, the protocols
in use, and the size and purpose of the test.
Endpoint
AIX
Operating
System
IBM AIX
v4.1.4 for
RS/6000
TCP/IP stack
IP
Multicast
TCP/IP stack
v4.1.4
included in AIX
http://www.ganymede.com/support/endpoints/endpoints_specs.phtml (1 of 4) [3/14/2000 8:23:01 AM]
QoS for
IP
Network
n/a
APPC stack
n/a
IPX/SPX
stack
n/a
Compaq
Tru64
UNIX
Digital UNIX
TCP/IP stack
v4.0B or
included in
Compaq
Tru64 UNIX Digital UNIX
for Alpha
v4.0B
n/a
n/a
n/a
Supported
on RaQ2
n/a
n/a
n/a
Cobalt
RaQ
Linux
TCP/IP stack
included in
Linux
HP-UX
HP-UX
v10.10 or
later
TCP/IP stack
included in
HP-UX
v10.10
n/a
n/a
n/a
IRIX
SGI IRIX
v6.2 with
patches
TCP/IP stack
included in
IRIX
v6.2 with
patches
n/a
n/a
n/a
Linux
a Linux v2.0
system, such
as Red Hat
(kernel
2.0.32)
TCP/IP stack
included in
Linux
kernel
2.0.32
(such as
Red Hat
v5.0)
n/a
n/a
n/a
MVS
IBM
MVS/ESA
SP v4r2.2 or
later
see MVS
TCP/IP stacks
below for the
supported
TCP/IP stacks
n/a
n/a
IBM ACF/VTAM
for MVS/ESA
v3r4.2 or later
n/a
NetWare
Novell
NetWare
v5.0, v4.x, or
3.12
TCP/IP stack
included in
NetWare
n/a
n/a
IPX/SPX
stack
included
in
NetWare
OS/2
IBM OS/2
Warp 4; or
OS/2 Warp
Connect 3; or
OS/2 v2.11
OS/2 Warp 4;
or OS/2 Warp
Connect 3; or
TCP/IP v 4.1
for OS/2
n/a
Novell
IBM
NetWare
Communications
Client for
Server for OS/2 v5
OS/2
or v4.1
v2.12
v5.0 or
v4.x
TCP/IP
TCP/IP
v4.1 for
OS/2
TCP/IP stack
included in
SCO UnixWare
v7.0
n/a
n/a
n/a
Sun Solaris Sun Solaris

for SPARC 2.4 or later
TCP/IP stack
included in Sun
Solaris
v2.4
n/a
n/a
n/a
Sun Solaris Sun Solaris

for x86
2.4 or later
TCP/IP stack
included in Sun
Solaris
v2.4
n/a
n/a
n/a
Windows
3.1
Microsoft
Windows 3.1
or Windows
for
Workgroups
3.11
see Windows
3.1 TCP/IP
stacks below
for the
supported
TCP/IP stacks
Endpoint 2
only 1
n/a
n/a
n/a
Windows
95 or
Windows
98
Microsoft
Windows 98
or Windows
95
TCP/IP stack
included in
Windows 98; or
Windows 95,
with the latest
WinSock2
Windows
98
supports
RSVP
IBM
PCOMM
v4.11 for
Windows
95
Windows 98;
Novell Client32
for Windows 95;
or Microsoft
Windows 95B
Windows
NT for
x86
Windows
2000 beta
3 or later
Microsoft SNA
Server v4.0 with
SP 1 or v3.0 with
SP 2; or IBM
Communications
Server for
Windows NT
v1.0; or IBM
PCOMM for
Windows NT
v4.11
IPX/SPX
stack
included
in
Windows
NT
SCO
UnixWare
SCO
UnixWare
v2.1 and 7.0
Microsoft
Windows NT
for x86 4.0 or
3.51,
workstation
Windows
or server. We
NT for x86 have done
preliminary
testing with
Windows
2000 beta
versions.
TCP/IP
(WinSock)
stack included
in Windows
NT. Windows
NT 4.0 Service
Pack 3 is
recommended.
NT 4.0
with
Service
Pack 3
Windows
NT for
Alpha
Microsoft
Windows NT
for Alpha
4.0,
workstation
or server
TCP/IP
(WinSock)
stack included
in Windows NT
4.0. Service
Pack 3 is
recommended.
NT 4.0
with
Service
Pack 3
Windows
2000 beta
3 or later
Microsoft SNA
Server for Alpha
v4.0 with SP 1 or
v3.0 with SP 2
IPX/SPX
stack
included
in
Windows
NT
Because of the lack of thread support, you cannot use Windows 3.1 as Endpoint 1 in an IP Multicast test.
Windows 3.1 TCP/IP stacks

The Windows 3.1 Performance Endpoint software supports the following TCP/IP stacks:
Microsoft 32-bit stack, shipped on the Windows NT 4.0 Server CD-ROM
Frontier Technologies SuperTCP v2.2
FTP Software OnNet for Windows v2.1
NetManage Chameleon NFS v4.6.3 (Multicast support requires version 7.0 or later)
Novell Client32 for DOS and Windows 3.1x v2.11
Novell Client for DOS/Win (VLMs) v1.21
WRQ TCP Connection for Windows v5.1
MVS TCP/IP stacks

The MVS Performance Endpoint software supports the following TCP/IP stacks:
TCP/IP version 3.2, through 3.6 from IBM. Also OS/390 version 2, releases 4, 5, and 6.
TCPaccess version 4.1 and 5.2, from Interlink Computer Sciences. A set of PTFs is required for operation
with version 4.1.
The MVS endpoint version 3.3 does not support testing with IP Multicast or RTP.
Ganymede: Endpoint Documentation
Endpoint Documentation
Endpoint 3.4 Manual (10/99)
Provides detailed information about installing and configuring Performance
Endpoints on different operating systems.
Endpoint 3.4 Manual (719K, 182 pages)
Click here for the Cobalt RaQ Quick Install Guide and Readme.

http://www.ganymede.com/support/endpoints/endpoints_docs.phtml (1 of 2) [3/14/2000 8:23:04 AM]
Ganymede: Endpoint Documentation
http://www.ganymede.com/support/endpoints/endpoints_docs.phtml (2 of 2) [3/14/2000 8:23:04 AM]
Ganymede: Endpoint Third Party Updates
Endpoint Third Party Updates

systems neccessary to run Ganymede Software Products.
Download Application Scripts
Operating Systems
IBM AIX
Compaq Tru64 UNIX for Alpha
FreeBSD
HP-UX
SGI IRIX
http://www.ganymede.com/support/endpoints/endpoints_third.phtml (1 of 6) [3/14/2000 8:23:08 AM]
Linux
IBM MVS
Novell NetWare
IBM OS/2
SCO UnixWare
Sun Solaris
Microsoft Windows 3.x Microsoft Windows 95
Microsoft Windows NT
IBM AIX
AIX Customer support - IBM's technical support page.

Digital UNIX home page - The general information area.
Digital's Service site - Searchable database of a variety of Digital product

issues.
FreeBSD
FreeBSD home page - The general information area
HP-UX
Hewlett Packard's home page
Sun/HP-UX Interoperability Guide
AIX/HP-UX Interoperability Guide
SGI IRIX
The IRIX support page
Download the required patches for IRIX version 6.2 You will be adked
for an SGI user name and password; this page requires your membership
in the Supportfolio Online service by Silicon Graphics, Inc)
Linux
The Linux home page
The Caldera home page
The home page of Debian
Infomagic's home page
The home page of Red Hat
The TurboLinux home page
IBM MVS
About eNetwork Communications Server
eNetwork Communications Server Library
Basic information about what used to be called Big Iron.
The entry point to support services.
Novell NetWare
Novell's support page
Novell's NetWare clients - download the latest versions of the NetWare

clients.
IBM OS/2
An OS/2 Warp 4 - TCP/IP Fix, so32dll.zip. Download and 'Unzip' the
file. Then look at 'README.TXT' for installation instructions.
Network Client for OS/2 v2.12
Directory of /pub/tcpip/os2 IBM's software repository.
SCO UnixWare
SCO Support and Services
Sun Solaris
Sun's home page
Sun Product Documentation including Manuals, Guides, AnswerBooks, and
man Pages.
Microsoft Windows 3.x

WRQ's tech support page, with information and support for Reflection for
Windows.
Microsoft's tech support page, with information and support for 32 Bit
Client for Windows 3.x.
Frontier Technologies home page, with information and support for

SuperTCP.
FTP Software home page, with information and support for OnNet.
NetManage home page, with information and support for Chameleon.
Kernel32 - An update of KERNEL32.DLL from Microsoft, which fixes a
memory leak when opening and closing network connections using
Windows Sockets in Win 95. The Kernel32 Update is newer than Service
Pack 1. Be sure to apply the Kernel32 Update after applying the Service
Pack.
Windows 95 Service Pack 1 - Windows 95 update from Microsoft. This
Service Pack does not include the Kernel32 update (see above).
IntranetWare Client 2.12 for Windows 95 - The Novell protocol stack for
IPX/SPX testing with Windows 95. Also provides support for IP
protocols.
Windows Sockets 2 for Windows 95 - You MUST HAVE either this
update, the following stack from Novell, or the OSR2 (OEM Service
Release 2) version of Windows 95, in order to do IPX/SPX testing with
Windows 95. An alternate location: for FTP retrieval
Deactivating HPR with IBM Communications server and IBM PCOMM An IBM Personal Communications fix to allow deactivation of HPR in
cases where it slows performance.
Windows 98 Home Page
Windows NT Service Packs - Updates (Service Packs) for Windows NT
from Microsoft.
A Windows NT TCP/IP Whitepaper, on implementing TCP/IP.

Documents those pesky registry keys, and their default values. Applies to;
Microsoft Windows NT 3.5/3.51/4.0: TCP/IP Protocol Stack and
Services, Version 2.0.
Deactivating HPR with IBM Communications Server and IBM PCOMM
- An IBM Personal Communications and IBM Communications Server
fix to allow deactivation of HPR in cases where it slows performance.
Personal Communications fix - A fix (for versions 4.1 and 4.11) to allow
Chariot Endpoint 1 to correctly return test results back to the Chariot
Console over APPC.
Microsoft SNA Server,and other BackOffice products, trial download and
information site.
Ganymede: Application Scanner Technical Support
Application Scanner Technical Support

third-party software and download documentation for Application Scanner.
http://www.ganymede.com/support/appscan/index.phtml (1 of 2) [3/14/2000 8:23:10 AM]
Ganymede: Application Scanner Technical Support
http://www.ganymede.com/support/appscan/index.phtml (2 of 2) [3/14/2000 8:23:10 AM]
Ganymede: Application Scanner FAQ
Application Scanner FAQ

What are the new capabilities in Application Scanner 1.2?
What are the prerequisites for using the Application Scanner?
Why is Service Pack 4 recommended? What happens if I use Application
Scanner on systems with Service Pack 3?
Application Scanner requires WinSock 2. Does that mean that my application
has to make WinSock 2 calls?
Will the Application Scanner work with Chariot and Pegasus?
If I need the Application Scanner on diskettes, what should I do?
Once I have purchased the Application Scanner is it OK for me to leave the
Application Scanner installed on my system?
Can I get an evaluation copy of the Application Scanner?
What are the known limitations of the Application Scanner today?
http://www.ganymede.com/support/appscan/appscan_faq.phtml (1 of 12) [3/14/2000 8:23:17 AM]
Are there any applications that you know cannot be traced by Application
Scanner?
What if I want to create a script for an application type (e.g., SNA) that is not
currently supported by the Application Scanner?
Will the Application Scanner create a script for Microsoft Exchange (e.g.,
Outlook)?
Will the Application Scanner create a script for web browsers?
Will Application Scanner trace applications that use Accepts?
If the application that is being traced generates multiple streams of traffic, how
do I know which streams to convert into scripts?
What should I do if I am unsuccessful at tracing an application that appears to
meet the Application Scanner prerequisites?
Can I have access to the trace information that is collected?
What is the maintenance fee for the Application Scanner?
Why should I purchase maintenance with the Application Scanner?
Why isn't my application being traced?
Why do the number of Sends and Receives on the main window not match what
is in the generated script?
Why are DNS and Internet Explorer Notify grayed out?
What are the new capabilities in Application Scanner 1.2?
Application Scanner 1.2 lets you create scripts for a much broader range of
applications than earlier versions. We think you will also find it much easier to
use.
Application Scanner can now capture a trace for complex transactions,

containing multiple simultaneous connections. The application being
traced can be both the source and destination for connections. You can
generate scripts for any or all of the traced connections.
Script optimization is performed when needed, to keep the number of
Sends and Receives small (under around 1,000); this makes the script
easier to manipulate in Chariot and Pegasus Network Monitor. By default,
Send and Receive pairs of the same size are compressed. Additionally,
Send and Receive sizes within specified ranges and averages are
combined to decrease the script size. Application Scanner lets you know
how much optimization was performed, if any, on all scripts that are
created.
It is now easier to identify which process needs to be traced. A new
column in the Application Selection dialog shows the last time a WinSock
call was made for each active application or process. This list can be
sorted by time or application/process name. A new Refresh button lets
you see if anything changed recently.
You can save and open the traces created by Application Scanner. The
binary trace file can be saved and reloaded later.
What are the prerequisites for using the Application Scanner?

Software Requirements:
Windows 98
Windows NT 4.0 (Service Pack 4 or later recommended)
Windows 95 with WinSock2
Hardware Requirements:
A Pentium processor or better
At least 16 MBytes of RAM (32 MBytes recommended)
At least 7 MBytes of available disk space
A web browser is required for viewing the online help.

A CD-ROM drive is required for installation.
Why is Service Pack 4 recommended? What happens if I use Application

Scanner on systems with Service Pack 3?
If you have Service Pack 3 installed, you will probably be able to trace most of
your applications. However, we have identified several reasons to recommend
upgrading to Service Pack 4 (or later) before using Application Scanner:
You will not be able to trace Microsoft Exchange on Windows NT
systems that do not have Service Pack 4 or later.
Application Scanner causes conflicts with applications containing the
WinSock calls ReadFile and WriteFile on Windows NT with Service
Pack 3. For example, Microsoft's IIS and Peer Web Services use these
calls. You must install Windows NT Service Pack 4 or later to use an
application with these calls.
We have found that there is a memory leak in Service Pack 3 when using
Application Scanner's Layered Service Provider (LSP). This defect is
fixed in Service Pack 4. If you are using Windows NT 4 with Service
Pack 3, we recommend that you install Application Scanner, collect the
traces that you need and then uninstall Application Scanner.
Application Scanner requires WinSock 2. Does that mean that my

application has to make WinSock 2 calls?
No, your applications can make sockets or WinSock calls. However, the
WinSock 2 DLL must be installed on the computer where Application Scanner
is installed and used. WinSock 2 is available as a part of Windows NT and
Windows 98. You can download WinSock 2 for Windows 95 from the
Microsoft web site.
Will the Application Scanner work with Chariot and Pegasus?

Scripts generated by the Application Scanner will work with Chariot 2.2 or later,
and Pegasus Network Monitor 1.2 or later.
If I need the Application Scanner on diskettes, what should I do?

The Application Scanner is shipped on CD-ROM. However, WinZip 7.0 makes
it easy to create Zip files that "span" multiple disks. To make a Zip file that
spans multiple disks, simply create a Zip file on a diskette, then add files to the
Zip as you normally would. If the disk fills during the Add operation, you will
be prompted for another disk. Simply insert the next disk and click the OK
button.
Three diskettes will be required to Zip the Application Scanner to diskette.
For example, to zip Application Scanner from the E: (CD-ROM) drive to
A:\APPSCAN.ZIP, you would:
1. Start WinZip Classic.
2. Select New to create a new archive.
3. Ensure that your diskette drive (A:\) is selected as the destination for the
new archive.
4. In the Drop dialog box, type the filename of the Zip file
(A:\APPSCAN.ZIP). Click OK.
5. Use the upper Drop dialog box to find the Application Scanner INSTALL
folder (E:\INSTALL) and then select all files within that folder.
6. Click the Add button.
7. You will be prompted for additional diskettes as needed.
Once I have purchased the Application Scanner is it OK for me to leave the

Application Scanner installed on my system?
The Application Scanner license does not prevent you from having the
Application Scanner installed on multiple systems, as long as it is only used on
one system at a time. However, as a rule, you should uninstall the Application
Scanner when it is not in use for the following reasons:
Overall application network performance may be impacted.
Since the Application Scanner intercepts all Winsock calls made to the
TCP/IP protocol stack, all applications using the Winsock interface may
experience a slight performance decrease (less than 5%) while the
Application Scanner is installed. This decrease will occur even when the
Application Scanner is not running.
In certain circumstances, the Application Scanner may prevent other
applications from running. For example, use of the Application Scanner
on a system with Windows NT 4 Service Pack 3 will conflict with
applications using certain Winsock calls. Installation of Service Pack 4
will prevent this conflict; however, the customer may not yet be willing to
upgrade their operating system. (See "Known Limitations" on page 2 of
the documentation for more details.)
By uninstalling the Application Scanner after use, you can avoid the above
situations.
Can I get an evaluation copy of the Application Scanner?

We have not provided an evaluation copy of the Application Scanner due to the
nature of its use. If you require an evaluation prior to purchase, please contact
your Ganymede sales manager to inquire about an onsite demonstration.
What are the known limitations of the Application Scanner today?

TCP or UDP only
The WinSock API only supports TCP and UDP protocols so these are the
only type of applications that Application Scanner supports.
Only traces WinSock API calls, on Windows 95, 98, or NT
Application Scanner only works with applications that make WinSock
calls on Windows 95, 98, or NT. Application Scanner does not trace
application calls that bypass the WinSock API. For example, remote file
access through Explorer bypasses the WinSock API, so Application
Scanner can not create a script for this application.
Conflicts with some applications on Windows NT with Service Pack 3
The Application Scanner causes conflicts with applications containing the
WinSock calls ReadFile and WriteFile on Windows NT with Service
Pack 3. Microsoft IIS Server and Peer Web Services use these calls. You
must install Windows NT Service Pack 4 to use an application with these
calls. Also, Service Pack 4 or later is required to trace Microsoft
Exchange.
Generated scripts ignore QoS information
Application Scanner traces GQoS API calls related to Quality of Service
(QoS) for TCP/IP, but cannot incorporate the QoS information into a
script.
Requires an Uninstall and Re-install if you add a new protocol stack
If you add a new protocol stack to your computer, it is required that you
Uninstall and Re-install Application Scanner. This is because the new
protocol installation will reorder the protocol layers, which can possibly
disable the installed protocol.
This information is also available under "Known Limitations" on page 2 of the
Application Scanner documentation.
Are there any applications that you know cannot be traced by Application
Scanner?
Application Scanner will not trace remote file access since it bypasses the
WinSock API. Also, Application Scanner will not trace 16-bit applications on
Windows 95/98.
What if I want to create a script for an application type (e.g., SNA) that is
not currently supported by the Application Scanner?
For applications that are not currently supported by the Application Scanner,
you should contract with the Ganymede Customer Care team to provide the
appropriate scripts for a fee.
Will the Application Scanner create a script for Microsoft Exchange (e.g.,
Outlook)?
Service Pack 4 or later is required to trace Microsoft Exchange transactions.
Will the Application Scanner create a script for web browsers?

Yes, the Application Scanner will trace a web browser. After the trace has been
stopped, you will be presented with information about all connections used
during the time that Application Scanner was tracing. You will then have the
option to create scripts for one or all of the identified streams of traffic.
Will Application Scanner trace applications that use Accepts?

Yes. The previous limitation that Application Scanner would only trace pure
client transactions (i.e., no Accepts of incoming connections) has been removed
with this release. However, if the application uses Accept commands,
Application Scanner will change the script such that the traced computer will be
Endpoint 2 in the script rather than Endpoint 1 (which is the normal case for a
"client" computer).
If the application that is being traced generates multiple streams of traffic,

how do I know which streams to convert into scripts?
Application Scanner creates scripts for a single stream at a time. If the
application traced creates multiple streams you should select the stream that
represents the largest percentage of the traffic or commands generated by the
application as the stream that best represents that application. Often,
applications with multiple streams will include one primary stream, along with
other control streams, such as DNS streams.
What should I do if I am unsuccessful at tracing an application that

appears to meet the Application Scanner prerequisites?
You should contact Ganymede's Customer Care team to report the problem. You
should provide as much information as possible about the type of application
being traced, as well as the system environment (e.g., operating system, service
pack level).
Can I have access to the trace information that is collected?

Currently, the trace information is not available to end users. We expect to make
this level of information available to end users in a later release.
What is the maintenance fee for the Application Scanner?

The maintenance fee is the same as for other Ganymede products-18% of the
original purchase charge.
Why should I purchase maintenance with the Application Scanner?

Purchasing maintenance with the Application Scanner entitles you to:
Assistance in using the Application Scanner
Assistance in creating scripts for applications that cannot be automatically
generated by the Application Scanner
Future updates of the Application Scanner (current plan is to have another
release in 4Q99)
Why isn't my application being traced?

There are several reasons for an application not being traced:
Your application may not be making WinSock calls, or the WinSock calls
may be bypassing the WinSock API.
Only TCP and UDP applications use the WinSock API and can therefore
be traced by Application Scanner. You may be tracing an RPC application
that is communicating directly with the underlying device driver rather
than the WinSock API. Also, remote file access applications also bypass
the WinSock API. (See Known Limitations on page 2 of the Application
Scanner documentation.)
You did not restart the application that you are trying to trace.
If the application you want to trace was running when you installed
Application Scanner, you must exit the application and restart it.
Application Scanner can only trace WinSock calls that go through the
LSP. If the application was running before the LSP was installed, the
WinSock calls cannot go through the LSP until you close and restart the
application.
You may have selected the wrong process to trace.
If you are unsure of the process to trace, you can look at the Choose an
active application or process dialog and press the Refresh button to check
the times of when the last WinSock API call was made. The process or
application with the most recent WinSock calls is probably the one you
want to trace.
You may be trying to trace an application that requires Service Pack 4.
See the Limitations section of the Application Scanner documentation.
Why do the number of Sends and Receives on the main window not match
what is in the generated script?
In order to generate scripts that are usable in Chariot and Pegasus Network
Monitor, some optimization techniques are used to combine Sends and Receives
when possible and appropriate. In some cases, optimization may occur that
makes the resulting script look less like the real application, possibly
invalidating the script. You will be notified by Application Scanner if
optimization is used and to what extent it is used. See "Script Optimization" on
page 13-14 of the Application Scanner User Guide for a detailed description of
optimization procedures.
Why are DNS and Internet Explorer Notify grayed out?

Both DNS and Internet Explorer Notify streams are grayed out, and therefore
scripts cannot be created for them. This is because they are not really part of the
traffic generated by the transaction that you traced. The DNS entries are created
by the Domain Name Server address resolution and these will occur naturally
when you use the script in Chariot or Pegasus Network Monitor based on the
network configuration. The Internet Explorer Notify stream is a set of one-byte
messages that Internet Explorer sends to itself. These messages are internal to
Internet Explorer and do not cross your network.
919-469-0997 (voice)
919-469-5553 (fax)
customer care team.
Ganymede: Application Scanner Documentation
Application Scanner Documentation

Application Scanner Manual (7/99)
scripts.
Application Scanner Manual (198K, 40 pages)

http://www.ganymede.com/support/appscan/appscan_doc.phtml (1 of 2) [3/14/2000 8:23:20 AM]
Ganymede: Application Scanner Documentation
http://www.ganymede.com/support/appscan/appscan_doc.phtml (2 of 2) [3/14/2000 8:23:20 AM]
Ganymede: Application Scripts Techncial Support
Application Scripts Techncial Support

One of the unique characteristics of Chariot and Pegasus is their ability to
emulate any type of networked application. The Application Script Library
makes that even easier. In addition to the scripts available with the individual
products, the Script Library provides an additional resource for finding the
application script that best fits your needs.
The scripts within the Script Library are provided by both Ganymede Software
and its customers. While submitted scripts are reviewed prior to being included
in the Script Library, we cannot guarantee that a particular script will be
applicable to your specific environment. We have attempted to provide enough
detailed information about each script so that you can decide if the script is
appropriate for your needs, or how you might need to modify it to meet your
needs.
http://www.ganymede.com/support/scripts/index.phtml (1 of 2) [3/14/2000 8:23:23 AM]
Ganymede: Application Scripts Techncial Support
http://www.ganymede.com/support/scripts/index.phtml (2 of 2) [3/14/2000 8:23:23 AM]
Ganymede: Application Script FAQ
Application Script FAQ

FTP program vs FTP script, why do I get different results?
What does the value DEFAULT mean in the scripts?
Can I import the new Chariot multimedia scripts (voice over IP, IP Multicast,
RealMedia, etc.) into Pegasus?
What happens to the loop variable values when I import a Chariot script into
Pegasus?
What happens to the loop variable values when I import a Chariot script into
Pegasus?
FTP program vs FTP script, why do I get different results?
This is really a case of apples and oranges. The FTPGET and FTPPUT scripts
http://www.ganymede.com/support/scripts/scripts_faq.phtml (1 of 5) [3/14/2000 8:23:27 AM]
are designed to emulate ALL of the activity that surrounds the actual file
transfer portion of an FTP transaction, while the value displayed after a GET or
PUT command has executed, shows the result of a single data flow in one
direction. This is easy to see by examining (editing) the FTPGET or FTPPUT
scripts. Notice that, after the timer has been started, the script executes a
connection sequence (4 flows), then 4 more flows, before the actual file transfer
is even begun. This is not good, if your objective is to find the maximum
throughput across a link. A much better choice would be to use the script named
PACKETLR, and compare it to the FTP program doing a GET command. You
should never use PACKETL or the PUT command to measure throughput. Even
after following this advice you may see different results due to an FTP programs
using special parameters when calling the program interface, which cause a
different window size to be used by the FTP program.
What does the value DEFAULT mean in the scripts?

The keyword DEFAULT means to use the default buffer size for the API of the
protocol and platform on which the endpoint is running. The default values, in
bytes, are:
OS
APPC
send /
receive
TCP send SPX send

/ receive
/ receive
UDP
send /
receive
IPX send
/ receive
MVS
32763 /
32767
32767
n/a
8183
n/a
OS/2
32763 /
32767
32767
32767
8183
537
NetWare
n/a
32767
32767
8183
1391 v4.x
537 v3.12
Unix(all)
n/a
32767
n/a
8183
n/a
n/a
4096 /
32767
n/a
8183
n/a
Win 95/98 n/a
4096 /
32767
4096 /
32767
8183
1391
32767
32767
8183
1391
Win 3.1
Win NT
32763 /
32767

You can import application scripts into Pegasus from Chariot and from our Web
site. See page 148 of the Pegasus 1.2 User Guide for instructions.
Can I import the new Chariot multimedia scripts (voice over IP, IP
Multicast, RealMedia, etc.) into Pegasus?
No. Pegasus 1.2 does not support the new Chariot multimedia scripts.
into Pegasus?
preserved. You shoul always modify newly imported Chariot scripts to ensure
set to "1".
into Pegasus?
preserved. You shoul always modify newly imported Chariot scripts to ensure
set to "1".
919-469-0997 (voice)
919-469-5553 (fax)
customer care team.
Ganymede: Application Script Documentation
Application Script Documentation

scripts.
Messages and Application Scripts Manual (1.2MB, 200 pages)

http://www.ganymede.com/support/scripts/scripts_doc.phtml (1 of 2) [3/14/2000 8:23:29 AM]
Ganymede: Application Script Documentation
http://www.ganymede.com/support/scripts/scripts_doc.phtml (2 of 2) [3/14/2000 8:23:29 AM]
Ganymede: Technical Support Download Center
Technical Support Download Center

systems neccessary to run Ganymede Software Products.
Download Application Scripts
Operating Systems
IBM AIX
FreeBSD
HP-UX
SGI IRIX
http://www.ganymede.com/support/download/index.phtml (1 of 6) [3/14/2000 8:23:34 AM]
Linux
IBM MVS
Novell NetWare
IBM OS/2
SCO UnixWare
Sun Solaris
Microsoft Windows 3.x Microsoft Windows 95
IBM AIX
AIX Customer support - IBM's technical support page.

Digital UNIX home page - The general information area.
Digital's Service site - Searchable database of a variety of Digital product

issues.
FreeBSD
FreeBSD home page - The general information area
HP-UX
Hewlett Packard's home page
Sun/HP-UX Interoperability Guide
AIX/HP-UX Interoperability Guide
SGI IRIX
The IRIX support page
Download the required patches for IRIX version 6.2 You will be adked
for an SGI user name and password; this page requires your membership
in the Supportfolio Online service by Silicon Graphics, Inc)
Linux
The Linux home page
The Caldera home page
The home page of Debian
Infomagic's home page
The home page of Red Hat
The TurboLinux home page
IBM MVS
About eNetwork Communications Server
eNetwork Communications Server Library
Basic information about what used to be called Big Iron.
The entry point to support services.
Novell NetWare
Novell's support page
Novell's NetWare clients - download the latest versions of the NetWare

clients.
IBM OS/2
An OS/2 Warp 4 - TCP/IP Fix, so32dll.zip. Download and 'Unzip' the
file. Then look at 'README.TXT' for installation instructions.
Network Client for OS/2 v2.12
Directory of /pub/tcpip/os2 IBM's software repository.
SCO UnixWare
SCO Support and Services
Sun Solaris
Sun's home page
Sun Product Documentation including Manuals, Guides, AnswerBooks, and
man Pages.
Microsoft Windows 3.x

WRQ's tech support page, with information and support for Reflection for
Windows.
Microsoft's tech support page, with information and support for 32 Bit
Client for Windows 3.x.
Frontier Technologies home page, with information and support for

SuperTCP.
FTP Software home page, with information and support for OnNet.
NetManage home page, with information and support for Chameleon.
Kernel32 - An update of KERNEL32.DLL from Microsoft, which fixes a
memory leak when opening and closing network connections using
Windows Sockets in Win 95. The Kernel32 Update is newer than Service
Pack 1. Be sure to apply the Kernel32 Update after applying the Service
Pack.
Windows 95 Service Pack 1 - Windows 95 update from Microsoft. This
Service Pack does not include the Kernel32 update (see above).
IntranetWare Client 2.12 for Windows 95 - The Novell protocol stack for
IPX/SPX testing with Windows 95. Also provides support for IP
protocols.
Windows Sockets 2 for Windows 95 - You MUST HAVE either this
update, the following stack from Novell, or the OSR2 (OEM Service
Release 2) version of Windows 95, in order to do IPX/SPX testing with
Windows 95. An alternate location: for FTP retrieval
Deactivating HPR with IBM Communications server and IBM PCOMM An IBM Personal Communications fix to allow deactivation of HPR in
cases where it slows performance.
Windows 98 Home Page
Windows NT Service Packs - Updates (Service Packs) for Windows NT
from Microsoft.
A Windows NT TCP/IP Whitepaper, on implementing TCP/IP.

Documents those pesky registry keys, and their default values. Applies to;
Microsoft Windows NT 3.5/3.51/4.0: TCP/IP Protocol Stack and
Services, Version 2.0.
Deactivating HPR with IBM Communications Server and IBM PCOMM
- An IBM Personal Communications and IBM Communications Server
fix to allow deactivation of HPR in cases where it slows performance.
Personal Communications fix - A fix (for versions 4.1 and 4.11) to allow
Chariot Endpoint 1 to correctly return test results back to the Chariot
Console over APPC.
Microsoft SNA Server,and other BackOffice products, trial download and
information site.
Ganymede: Ganymede Software Education
Ganymede Software Education

Ganymede Software's products are known for their ease of use and tremendous
flexibility. Our educational courses build on these product strengths and provide
IT professionals with the knowledge and confidence needed to effectively
manage the performance of the IT infrastructure. Ganymede's courses are
designed to enable the user to get the most out of their product investment by
providing a solid background, reinforced by hands-on, "real world" exercises.
http://www.ganymede.com/support/education/index.phtml (1 of 2) [3/14/2000 8:23:38 AM]
Ganymede: Ganymede Software Education
http://www.ganymede.com/support/education/index.phtml (2 of 2) [3/14/2000 8:23:38 AM]
Ganymede: Ganymede Software Training Overview
Ganymede Software Training Overview

Basic Operations Training
Advanced Testing Techniques
To register
For more info
Welcome to Chariot Training!

Ganymede Software's Chariot is known for its ease of use and tremendous
testing flexibility. These courses are designed to enable the user to get the most
out of their product investment by providing a solid background in Chariot
fundamentals, reinforced by hands-on, real-world exercises.
Class Schedules and Fees

Courses are scheduled for the following dates:
http://www.ganymede.com/support/education/register.phtml (1 of 3) [3/14/2000 8:23:42 AM]
Chariot Basic Operations Chariot Advanced Testing Techniques Location

February 8 Februrary 9 Santa Clara, CA
February 22 February 23 Research Triangle Park, NC
The fee for each course is $550 per attendee ($450 for customers covered by a
Software Maintenance Agreement). Training can also be presented at your site contact us for details.
Chariot Basic Operations (GY80-1001-1000T)

This hands-on, one-day course will prepare the student to succesfully deploy
Chariot, create meaningful test scenarios, and analyze results. The course is
delivered in a lecture/lab format, with concepts immediately demonstrated and
reinforced by lab exercises that utilize Chariot.
You will learn:
How Chariot's architecture produces real-world results
How to install Chariot in a lab or production network environment
How to use Chariot scripts, including tailoring standard scripts
How Chariot tests operate and how to control test parameters
How to create "real world" test scenarios for lab and production network
testing
How to interpret Chariot test results
Chariot Advanced Testing Techniques (GY80-1002-1000T)

This hands-on, one-day course will illustrate how to use Chariot to obtain
meaningful results for typical network performance testing situations. The
course is delivered in a lecture/lab format, with concepts immediately
demonstrated and reinforced by problem-solving exercises that utilize Chariot in
a variety of laboratory and production network scenarios. The Chariot Basic

Operations Course is a prerequisite for the Chariot Advanced Testing
Techniques Course.
You will learn:
How to create custom scripts using Application Scanner
Techniques for comparing different technologies, hardware components,
service providers, etc.
Techniques for application and capacity planning
Techniques for network performance benchmarking and troubleshooting
Techniques for automating Chariot testing
Techniques for tailoring Chariot output
To Register or Learn More...

Contact your local sales representative
Call us at 888-GANYMEDE (888-426-9633) or 919-469-0997Select
extension 301 to speak to Susan Elek
E-mail us at edu@ganymede.com
Ganymede: Directions to Ganymede
Directions to Ganymede
Ganymede Software
1100 Perimeter Park Drive
Suite 104
Driving directions from MapQuest!
Main Phone: 888-GANYMEDE (426-9633) or 919-469-0997
Sales Phone: 888-GANYMEDE (426-9633) Option #5
Tech Support Phone: 888-GANYMEDE (426-9633) Option #6
Fax: 919-469-5553
Company Internet Email: info@ganymede.com

Technical Support Email: support@ganymede.com
Career Opportunities Email: employ@ganymede.com
Webmaster Email: webmaster@ganymede.com
http://www.ganymede.com/support/education/directions.phtml (1 of 2) [3/14/2000 8:23:45 AM]
Ganymede: Directions to Ganymede
We are located near RDU International Airport off Airport Blvd. Our office
building is located at 1100 Perimeter Park Drive, Suite 104, approximately 1
mile off I-40 in Perimeter Park West.
From I-40 East
Take exit 284a (Airport Blvd West). At the top of the ramp, take a right to
merge onto Airport Road. Go straight through the stoplight and continue
on Airport Blvd.
From I-40 West
Take exit 284. At the top of the ramp, take a left onto Airport Blvd. Drive
over the I-40 overpass and continue on Airport Blvd. through two
stoplights.
From RDU Airport
Follow the airport exit signs towards I-40 West/Durham. This will put you
on Airport Blvd. After leaving the airport, continue on Airport Blvd. over
the I-40 overpass and through three stoplights.
You will pass a shopping mall on your right. The next stoplight will be Perimeter
Park Drive. Go straight through this light and take the first right into a parking
lot. As you enter this parking lot you will be facing the entrance to our building
(Suite 104).
http://www.ganymede.com/support/education/directions.phtml (2 of 2) [3/14/2000 8:23:45 AM]
Ganymede: Local Hotels
Local Hotels
La Quinta Inn Suites
(919) 461-1771 Tel
(919) 461-1721 Fax
http://www.laquinta.citysearch.com
1001 Hospitality Court
Across from the Prime Outlet Mall, I-40 exit 284. About mile from
Ganymede.
Courtyard by Marriott
(919) 467-9444 Tel
(919) 467-9332 Fax
http://www.marriott.com
2001 Hospitality Court
Ganymede.
http://www.ganymede.com/support/education/hotels.phtml (1 of 2) [3/14/2000 8:23:49 AM]
Ganymede: Local Hotels
Baymont Inn Suites

(919) 481-3600 Tel
(919) 460-1584 Fax
http://www.baymontinns.com
1001 Aerial Center Parkway
Beside the Prime Outlet Mall, I-40 exit 284. About mile from Ganymede.
Hampton Inn
(919) 462-1620 Tel
http://www.hamptoninn.com
1010 Airport Blvd
Ganymede.
Sheraton Imperial Hotel and Convention Center

(919) 941-5050 Tel
http://www.sheraton.com
4700 Emporer Blvd
Durham, NC 27703
Off Page Road, I-40 exit # 282. About 2 miles from Ganymede.
http://www.ganymede.com/support/education/hotels.phtml (2 of 2) [3/14/2000 8:23:49 AM]
Ganymede: Ganymede Software Professional Services
Ganymede Software Professional Services

Ganymede's Professional Services enables time-pressed corporations to
capitalize on the power and value of our products without deploying internal
resources and requiring the organization to keep advanced network expertise on
staff.
Experienced Ganymede Employees deliver and administer Professional Services
along with a range of other options. These network professionals understand
networking and communications infrastructures and have been thoroughly
trained. Ongoing training ensures that our employees stay abreast of the latest
networking developments and product enhancements.
http://www.ganymede.com/support/services/index.phtml [3/14/2000 8:23:52 AM]
Ganymede: Ganymede Service Offerings
Ganymede Service Offerings

Professional installation and configuration services to help you start up your
Pegasus System
Pegasus Startup Service is designed to insure the successful implementation of
your Pegasus system by providing you with the installation and configuration
training required to fully utilize the capabilities of Pegasus. In two days, your
Pegasus server will be set up and ready to monitor your network and produce
reports on the performance of your network.
Review Deployment Plan. Ganymede will review the deployment plan
that has been developed by the customer, using the deployment kit
provided by Ganymede, ensuring proper deployment of Pegasus Network
Performance Endpoints.
Installation of Pegasus Server Software. Customer Care engineers will
install the Pegasus Server Software on your Windows NT Server.
Connection Configuration. This component supports the creation of up to
25 endpoint pair connections on day one and additional connections on
day two as time permits.
Definition of Scheduled Reports. You can define and create up to 5
http://www.ganymede.com/support/services/offerings.phtml (1 of 3) [3/14/2000 8:23:56 AM]
scheduled reports that will automatically be produced according to the

schedule defined.
Report Analysis. Understand what the reports are telling you so that you
can fully utilize the information available from Pegasus. This will range
from detailed, on-demand, connection reports to integrated summary
reports for the CIO.
Maintenance and Troubleshooting. Learn how to maintain and
troubleshoot Pegasus.
Day 1
Review deployment plan

Install Pegasus server software
Configure Pegasus server
Define scheduled reports
Day 2
Report analysis
Maintenance & troubleshooting
Configure additional connections
Requirements
When hosting a start-up service engagement, customers are expected to provide
the following:
Installation planning checklist completed
Information entry form completed
At spec NT server installed
Other Services Available

The following additional services are currently available for Ganymede's
products. Contact your Ganymede account representative for additional
information.
Pegasus Basic Operation Training Class. One day on-site training class
for up to 5 individuals.
Chariot Basic Operation Training Class. One day on-site training class for
up to 5 individuals.
Ganymede Software
Chariot Training Registration Form

Select a class:
Chariot Basic Operations
Chariot Advanced Testing Techniques
*Select a date/location:
Santa Clara, CA - April 4-5, 2000
*Total Number of Attendees:
1
*Authorized by:
*Company/Organization:
*Address:
http://www.ganymede.com/support/education/regform.phtml (1 of 4) [3/14/2000 8:24:00 AM]
Ganymede Software
Address:
*City:
*State:
*Zip Code:
*Email Address:
*Telephone Number:
Fax Number:
Attendee #1
*Name:
*Email:
*Phone:
*Title:
Attendee #2
Name:
Email:
Phone:
Title:
Ganymede Software
Attendee #3
Name:
Email:
Phone:
Title:
Attendee #4
Name:
Email:
Phone:
*Method of payment:
Company Check
Credit Card (Mastercard/Visa only)
Company Purchase Order
Purchase Order Number: (if known)
Title:
Ganymede Software
Company Check
The check must be received 5 business days prior to the training session date.
Please make the check payable to Ganymede Software Inc. and mail to:
Accounts Payable
Morrisville, NC 27560-9119
Company Purchase Order
The purchase order must be received 5 business days prior to the training session
date. Please fax the purchase order to 919-468-9736.
Credit Card (MasterCard or Visa)
Download and complete the credit card payment form (pdf), then fax the completed
form to 919-468-9736.
Other Important Information
Lunch is served at the training facility. Do any attendees have special dietary
needs? If so, please contact us at edu@ganymede.com at least 5 days prior to the
training date.
If you have questions or prefer to register via phone, please call 888-GANYMEDE
or 919-469-0997, and enter extension 301. If you prefer to register by fax, please
print and complete this form, then fax it to 919-468-9736.
Cancellation Policy
If you cancel at least 5 days prior to the class, you may request a refund or you may
reschedule for the same class on a later date.
If you cancel less than 5 days prior to the class, you will receive no refund.
You may substitute an attendee at any time with no penalty.
Ganymede Software reserves the right to cancel a class at any time. In the event of
a cancellation, Ganymede Software will use its best efforts to notify registered
attendees as quickly as possible and arrange for registration in another scheduled
class, or for a refund of any monies already paid. In no event will Ganymede
Software be responsible for any attendee costs related to course cancellations,
including hotel or travel reservations.
Submit Request
Messages and Application Scripts
For:
Chariot 3.1
(June-99)
Copyright (C) Ganymede Software Inc., 1995-1999. All rights reserved.

1100 Perimeter Park Drive Suite 104
Morrisville, North Carolina 27560
U.S.A.
Web: http://www.ganymede.com/
ii
Contents
iii
Contents
Application Scripts
Summary of the Scripts .........................................................................................................2

Benchmark Scripts ................................................................................................... 2
Internet Scripts......................................................................................................... 3
Web Push Scripts..................................................................................................... 4
Business Scripts....................................................................................................... 5
Streaming Scripts..................................................................................................... 5
Script Commands, Parameters, and Variables....................................................................... 6
Communications Commands.................................................................................... 6
Application Commands........................................................................................... 12
Program Control Commands .................................................................................. 13
Rules for Scripts.................................................................................................................. 13
Overall Script Rules................................................................................................ 13
Command and Parameter Rules............................................................................. 15
Script Variable Rules .............................................................................................. 16
Setting Sleep Times ............................................................................................... 16
Setting the Send Data Rate .................................................................................... 19
Choosing the Datatype on the SEND Command ..................................................... 21
Listings of Application Scripts
23
BKWBSIGN Script (BackWeb Sign-up and InfoPak Download) ............................... 24

BKWBUPDT Script (BackWeb Update)................................................................... 26
CASTDL Script (Castanet Channel Download)........................................................ 28
CASTINIT Script (Castanet Initial Run) ................................................................... 30
CONN Script (Connectivity) .................................................................................... 32
CREDITL Script (Credit Check, long connection) .................................................... 33
CREDITS Script (Credit Check, short connections)................................................. 35
DBASEL Script (Database Update, long connection)............................................... 37
DBASES Script (Database Update, short connections) ........................................... 39
FILERCVL Script (File Receive, long connection).................................................... 41
FILERCVS Script (File Receive, short connections) ................................................ 43
FILESNDL Script (File Send, long connection) ........................................................ 45
FILESNDS Script (File Send, short connections)..................................................... 46
FTPGET Script (FTP get files) ................................................................................ 47
iv
FTPPUT Script (FTP put files) ................................................................................ 51

HDLNINIT Script (Headliner Initial Load) ................................................................ 55
HDLNUPDT Script (Headliner Subsequent Update) ................................................ 57
HTTPGIF Script (Web GIF download) .................................................................... 59
HTTPTEXT Script (Web text download).................................................................. 61
INQUIRYL Script (Inquiry, long connection)............................................................ 63
INQUIRYS Script (Inquiry, short connections) ........................................................ 65
IPTVA Script (Cisco IP/TV, MPEG audio stream) ................................................... 67
IPTVV Script (Cisco IP/TV, MPEG video stream) ................................................... 69
NETMTGA Script (NetMeeting v2.1 audio stream).................................................. 71
NETMTGV Script (NetMeeting v2.1 video stream).................................................. 73
NETSHOWU Script (NetShow UDP, 28.8 kbps) ..................................................... 75
NNTP Script (network news transfer protocol) ........................................................ 77
NOTESCHK Script (Lotus Notes, check for unread e-mail)..................................... 80
NOTESRCV Script (Lotus Notes, receive e-mail).................................................... 82
NOTESSND Script (Lotus Notes, send e-mail) ....................................................... 84
PACKETL Script (Packet Blaster, long send).......................................................... 86
PACKETLR Script (Packet Blaster, long receive).................................................... 88
PNTCAST1 Script (PointCast v1 Initial/Subsequent Update)................................... 90
PNTCAST2 Script (PointCast v2 Initial/Subsequent Update)................................... 92
POP3 Script (receive e-mail) .................................................................................. 94
REALAUD Script (RealAudio, CD streaming).......................................................... 97
REALMED Script (RealMedia, Stream Smart audio-video) ..................................... 99
SAPAUTHP Script (SAP R/3, authorize payment on invoice) ................................ 101
SAPINV Script (SAP R/3, prepare an invoice) ...................................................... 103
SAPLOGIN Script (SAP R/3, login)....................................................................... 105
SAPPUROR Script (SAP R/3, purchase order) ..................................................... 107
SMTP Script (simple mail transfer protocol).......................................................... 109
TELNET Script (remote terminal session)............................................................. 112
VOIPS Script (voice over IP send)........................................................................ 114
Messages
115
Index
195
Application Scripts
Application Scripts
Application scripts are key to how we measure network performance. They model the real applications you use
between computers in a network. They make the same API calls to the network protocol stacks that real
applications make, causing the protocol stacks to perform the same work involved in sending and receiving
data. Both Chariot and Pegasus use application scripts.
These scripts consist of commands, such as SEND and RECEIVE, as well as script variables, such as the size
of the buffer and the type of data in each SEND. Script commands and script variables are described in detail
below.
Application scripts are generally independent of the network protocol. This means the same script can be used
with any network protocol supported by the Performance Endpoints youre using. (A subset of the scripts,
called streaming scripts, require a datagram protocol, such as IPX, RTP, or UDP.)
Chariot and Pegasus use the same application scripts, but have different ways of storing them. Application
scripts are kept at the computer where you configure tests (that is, at the Chariot console or the Pegasus server);
scripts are only delivered to the endpoints when you start a test.
In Chariot, application scripts are stored in separate files. At installation time, these binary files are
installed in the SCRIPTS subdirectory in the directory where you installed the Chariot console. For example, if
you installed Chariot to D:\GANYMEDE\CHARIOT\, the script files are located in
D:\GANYMEDE\CHARIOT\SCRIPTS. You can choose to put the script files on a different drive or directory.
You may then want to update the Where to read script files field in the Directories tab of the User Settings
notebook. See the discussion Changing Default Directories in the Chariot User Guide.
Tests in Chariot start when you press the Run button or start RUNTST. Thats when the Chariot console
delivers the appropriate binary script to each Endpoint 1 in the test.
In Pegasus, application scripts are stored in the internal database at the Pegasus server. This lets you
access scripts remotely, since Pegasus Configuration uses Java. Thus, theyre not kept around in separate files,
as they are in Chariot. Using Pegasus import and export utilities, you can load script files into the Pegasus
server (import), or save application scripts into their own script files, which can be loaded by Chariot (export).
The 40-byte application script names must be unique in Pegasus, since the application script name appears
prominently in Pegasus reports.
Testing in Pegasus starts when you Add a Connection. Thats when the Pegasus server delivers the binary
script and its schedule to Endpoint 1 of a connection.
The user interfaces at Chariot and Pegasus offer dialogs for modifying the variables in any script, which can be
used in any connection. In addition, a Script Editor lets you modify existing script files or create your own
script files from scratch. The Script Editor reads and writes binary script files in the Chariot format; these
script files can be easily imported into Pegasus. The Script Editor is included with Chariot and the Application
Scanner.
If you would like to create custom scripts, you can also use the Application Scanner. The Application Scanner
lets you modify existing scripts, create new scripts from a template, and trace an application task to create a
script. The Script Editor is also included in Chariot.
In the following sections, we summarize the library of application scripts, grouping the application scripts into
several categories (see Summary of the Scripts on page 2). We next discuss the commands and variables
with which the scripts are constructed. These are followed by a discussion of the rules for scripts and their
variables enforced by the script editor (see Rules for Scripts on page 13). Lastly is the exhaustive description
of the application scripts shipped with this product (see Listings of Application Scripts on page 23).
Summary of the Scripts

We ship an extensive library of application scripts with our products. This library of application scripts
emulates applications in several categories.
A set of scripts emulates the Bader benchmarks or classic transactions; these Benchmark Scripts on page
2 can represent almost any client/server application.
A set of Internet Scripts on page 3 emulates network applications commonly available on todays
desktop operating systems.
Web Push Scripts on page 4 are also included in the Internet scripts and emulates the flows of Internet
push applications: BackWeb, by BackWeb Technologies; Castanet Tuner, by Marimba Inc.; Headliner, by
Lanacom (acquired July 1997 by BackWeb Technologies); and PointCast Network, by PointCast Inc.
A set of Business Scripts on page 5 emulates popular business applications: Lotus Notes and SAP R/3.
Dozens of other business scripts are available at our web site
(http://www.ganymede.com/download/scripts).
A set of Streaming Scripts on page 5 emulates multimedia applications: voice over IP, NetShow and
NetMeeting from Microsoft, RealAudio from RealNetworks, and IP/TV from Cisco Systems. These scripts
must be run over a datagram protocol: IPX, RTP, or UDP.
Ganymede Software continues to add scripts that emulate well-known applications. These will be available in
program updates and via our Web site. Contact us if you uncover situations where you need a specific script
thats not available.
Benchmark Scripts
The benchmark scripts come in two variations: long and short connections. You can tell by the last character
in their filename, which is either an L or an Sthose with L use long connections, those with S use short
connections. For scripts identified as long connections, a single connection is used for the entire test script, no
matter how many transactions are run. The time to start and stop the connections is not included in the
timings. For those identified as short connections, a new connection is started for each transaction. All
network protocols have overhead associated with connection startup and takedown. Having these two
variations of scripts allows you to decide how much of the startup/takedown overhead to factor into your tests.
We think these benchmark scripts allow you to emulate most transaction-oriented application designs.
Application Scripts
Here is a summary of the benchmark scripts.

Benchmark
Script
Script File Name
Description
Credit Check
CREDITL.SCR
CREDITS.SCR
These scripts emulate a series of credit approvals. A record is sent from

Endpoint 1. Endpoint 2 receives the record and sends back a
confirmation. The default record size is 100 bytes.
Database Update
DBASEL.SCR
DBASES.SCR
This is the most complex of the benchmarks. These scripts emulate a

program that requests a record from Endpoint 2, gets it, updates it and
sends it back. Lastly, Endpoint 1 receives a confirmation that the update
was completed. The default sizes for the request and the record are 100
bytes. (This script can be described as an Inquiry followed by a Credit
Check.)
File Transfer
(Receive)
FILERCVL.SCR
FILERCVS.SCR
These scripts emulate requesting a file and getting it back. The request
from Endpoint 1 defaults to 100 bytes. The default file size is 100,000
bytes.
File Transfer
(Send)
FILESNDL.SCR
FILESNDS.SCR
These scripts emulate sending a file from Endpoint 1 to Endpoint 2, and

getting a confirmation back. The default file size is 100,000 bytes.
Inquiry
INQUIRYL.SCR
INQUIRYS.SCR
These scripts emulate a typical client/server transaction. Endpoint 1

sends a request to Endpoint 2, which sends a reply back. Both the
request and reply default to 100 bytes. The script variables let you add
delays, and change the send and receive buffer sizes.
Packet Blaster
(Long Send) &
Packet Blaster
Reversed (Long
Receive)
PACKETL.SCR
PACKETLR.SCR
The PACKETL script sends packets, as quickly as possible, without

waiting for any kind of response. This is NOT a good test for gathering
performance information. Measurements can be inaccurate, because the
script ends without waiting for the receiving side to catch up. This test
uses the FLUSH script command. While it has no effect on TCP/IP, it
causes APPC to send data immediately, rather than waiting to fill
buffers.
The PACKETLR script receives packets, as quickly as possible, without
waiting for any kind of response. This script is similar to
PACKETL.SCR, but Endpoint 1 issues Receives instead of Sends.
Measurements are more accurate, since Endpoint 1 knows exactly how
many bytes have been received successfully in each timing record.
Internet Scripts
Our Internet scripts model applications frequently used on the Internet. We emulate the fetching of text and
GIF files from a Web server, getting and putting files using FTP, transferring network news using NNTP,
sending and receiving e-mail using SMTP and POP3, and doing remote terminal emulation with Telnet.
All application scripts let you set the port number for the connection. The port number is useful for accurate
modeling when using TCP and UDP, for example, but is ignored when using other protocols, such as APPC.
We have set the default port number in these scripts to AUTO, which gives the endpoints the most flexibility.
However, you may want to change the port number to more closely model your application environment; the
port numbers used by some applications on the Internet are listed in the Listings of Application Scripts on
page 23.
Here is a summary of the Internet scripts.

Internet Script
Script File Name
Description
FTP Get and Put
FTPGET.SCR
FTPPUT.SCR
These scripts emulate TCP/IPs FTP application. The default file size is
100,000 bytes.
Web Graphics and

Text Request
HTTPGIF.SCR
HTTPTEXT.SCR
These scripts emulate the transfer of graphics and text files from an
HTTP server. The default size of a graphics file is 10,000 bytes; for a
text file, the default is 1,000 bytes.
Network News
NNTP.SCR
This script emulates the transfer of network news across the Internet,
using the NNTP protocol.
Send and Receive

E-mail
POP3.SCR
SMTP.SCR
These scripts emulate typical e-mail transfers. The default size of an email message is 1,000 byte, with an additional 20-byte header.
Telnet
TELNET.SCR
This script emulates the byte-by-byte transfer of characters in TCP/IPs

Telnet application.
Web Push Scripts

The following set of application scripts emulates four of the popular Web Push applications: BackWeb,
Castanet Tuner, Headliner, and PointCast Network.
These Push scripts have their number_of_timing_records variable set to a default value of 50. One timing
record represents the transaction that occurs when the user of a Push client signs on or updates. The default
data type on all the SEND commands is NOCOMPRESS.
Some Push scripts download content from various sources in parallel. Youll need multiple concurrent
connections to emulate such applications.
Here is a summary of the Web Push scripts.
Web Push
Script
Script File Name
Description
BackWeb
BKWBSIGN.SCR
BKWBUPDT.SCR
These scripts emulate subscribing to a new BackWeb channel, and

updating an existing channel.
Castanet Tuner
CASTINIT.SCR
CASTDL.SCR
These scripts emulate running Castanet Tuner the first time, as well as
the download of a channel.
Headliner
HDLNINIT.SCR
HDLNUPDT.SCR
These scripts emulate the initial run of Headliner, as well as a

subsequent update.
PointCast
Network
PNTCAST1.SCR
PNTCAST2.SCR
These scripts emulate content updates, for PointCast Network versions 1

and 2.
Application Scripts
Business Scripts
The following set of application scripts emulates two popular business applications: Lotus Notes and SAP R/3.
Here is a summary of the business scripts.
Business Script
Script File Name
Description
Lotus Notes
NOTESCHK.SCR
NOTESRCV.SCR
NOTESSND.SCR
These scripts emulate e-mail exchanges in Lotus Notes. The

NOTESCHK script emulates checking for unread e-mail messages.
NOTESRCV emulates retrieving e-mail messages; NOTESSND
emulates the sending of multiple e-mail messages.
SAP R/3
SAPAUTHP.SCR
SAPINV.SCR
SAPLOGIN.SCR
SAPPUROR.SCR
These scripts emulate the network traffic in SAP R/3 Sales and
Distribution modules. The scripts are meant to be run together in
multiple-connection tests, with one script per connection.
Streaming Scripts
Streaming scripts emulate multimedia applications which send data without acknowledgments. Datagrams are
sent in one direction only, from Endpoint 1 to Endpoint 2. Streaming scripts have a fixed format; you cant
add, move, or delete commands in streaming scripts, although you can change their script variables.
Streaming scripts are used with IPX, RTP, or UDP. The endpoints running a streaming script do not require
reliable data delivery. When running a streaming script, Endpoint 2 keeps statistics on lost data and returns
this information as part of the results. If using the RTP protocol, Endpoint 2 records statistics on jitter and
returns this information as part of the test results.
IP Multicast is a subset of multimedia, which requires RTP or UDP and appropriate network configuration.
Multicast groups, which are used to test IP Multicast, must use a streaming script.
Typical multimedia applications use various packet sizes. When emulating such an application, you should
account for any header that may be included in the size of the packet. Endpoint multimedia support uses a 9
byte header for UDP and a 12 byte header for RTP. In addition to these headers, the protocol stack adds 8
bytes for the UDP protocol and 20 bytes for IP.
For example, if you are using UDP and the desired packet size is 512 bytes, the send buffer size should be 475
(512 9 8 20=475). If you are using RTP and the desired packet size is 512 bytes, the send buffer
size should be 472 (512 9 8 20=472).
Typical multimedia applications send data at a specified rate. All application scripts let you control their data
rate by modifying the send_data_rate script variable. Setting an appropriate send_data_rate is especially
important for streaming scripts, since they can easily consume all available bandwidth. None of the streaming
scripts are shipped with the send_data_rate set to UNLIMITED. We dont recommend the highest rate, the
UNLIMITED setting, except when doing stress testing.
Streaming scripts are not supported by Pegasus.
See Overall Script Rules on page 13 for information on rules specific to streaming scripts.
Here is a summary of the streaming scripts.

Streaming Script
Script File Name
Description
IP/TV
IPTVA.SCR
IPTVV.SCR
Cisco Systems IP/TV application, MPEG audio or video streams
NetMeeting
NETMTGA.SCR
NETMTGV.SCR
Emulates sending an audio or video stream using Microsoft

NetMeeting v2.1 over a 100 Mbps Ethernet LAN.
NetShow
NETSHOWU.SCR
Emulates the Microsoft NetShow application.
Real Audio, CD
Streaming
REALAUD.SCR
REALMED.SCR
Emulates Real Audio applications, by RealNetworks: CD streaming

and audio-video stream smart
Voice Over IP Send
VOIPS.SCR
Emulates a voice over IP session conducted by an equipment vendor

who is qualifying their equipment.
Script Commands, Parameters, and Variables

Here is detailed information about the script commands and the network calls that they cause. It is intended
for advanced users who want to know the details of the network flows that each script creates.
There are three categories of script commands: Communications Commands on page 6 (such as SEND and
RECEIVE), Application Commands on page 12 (such as SLEEP), and Program Control Commands on
page 13 (such as LOOP). These three categories are discussed separately below.
Communications Commands
The communications commands are independent of the network protocol; however, they obviously have to be
mapped to API calls at the endpoints. The mappings of commands to API calls are shown below in three
tables.
Mapping of Script Commands for APPCthe APPC programming interface is used for the SNA LU 6.2
protocol on all platforms where it is supported.
Mapping of Script Commands for Socketsthe Sockets programming interface is used for the TCP and
UDP protocols on all platforms, as well as for the IPX and SPX protocols on Windows 95/98 and Windows
NT.
Mapping of Script Commands for TLIthe TLI programming interface is used for the IPX and SPX
protocols on NetWare and OS/2.
Application Scripts
Mapping of Script Commands for APPC

Here are the mappings of the script commands to APPC calls.
See DEFAULT Values for the Endpoints on page 11 for the value of the keyword DEFAULT, used on the
buffer_size parameter.
Script Command
APPC
CONNECT_INITIATE (port_number ignored for APPC)
TP_STARTED
ALLOCATE
CONNECT_ACCEPT (port_number ignored for APPC)
RECEIVE_ALLOCATE
SEND (byte_count, buffer_size,

datatype)
Using SEND_DATA, send the number of bytes in byte_count, in

buffer_size chunks. The last buffer may be smaller than the buffer_size.
The maximum buffer_size value is 32767.
See Choosing the Datatype on page

21 for more on the datatype parameter.
RECEIVE (byte_count, buffer_size)
Issue RECEIVE_AND_WAIT calls in a loop, until the number of bytes

specified in byte_count have been received, in buffer_size chunks. The
last buffer received may be smaller than the buffer_size value. The
maximum buffer_size value is 32767.
CONFIRM_REQUEST
CONFIRM
CONFIRM_ACKNOWLEDGE
CONFIRMED. One byte is counted in the summary of bytes sent or

received.
DISCONNECT
Issue DEALLOCATE on the sending side; do memory cleanup on the

receiving side.
FLUSH
FLUSH
Mapping of Script Commands for Sockets

The Sockets programming interface is used for the TCP and UDP protocols on all platforms, as well as for the
IPX and SPX protocols on Windows 95/98 and Windows NT. The same port number is required for all the
CONNECT_INITIATE commands in a script.
Script Command
Sockets stream (for SPX and TCP)
Sockets datagram (for IPX and UDP)
CONNECT_INITIATE
(port_number)
socket()
bind()
connect()
socket()
bind() and connect(): once per
connection, per test
socket()
bind()
listen()
accept()
None.
Using write(), send the number of

bytes in byte_count, in buffer_size
chunks. The last buffer may be
smaller than the buffer_size. The
Using sendto() or send(), send the

number of bytes in byte_count, in
buffer_size chunks. The last buffer
may be smaller than the buffer_size.
Issue read() calls in a loop, until the

number of bytes specified in
byte_count have been received, in
received may be smaller than the
buffer_size value. The maximum
buffer_size value is 32767.
Issue recvfrom() or recv() calls in a

loop, until the number of bytes
specified in byte_count have been
received.
CONFIRM_REQUEST
receive()waits to receive the one

byte sent because of the partners
CONFIRM_ACKNOWLEDGE.
recvfrom() or recv()waits to receive

the one byte sent because of the
partners
CONFIRM_ACKNOWLEDGE
A one-byte data record is returned to

the partner endpoint which issued the
CONFIRM_REQUEST. This byte is
counted in the summary of bytes sent
or received.
Issue sendto() or send() to return a onebyte data record to the partner endpoint
which issued the
counted in the summary of bytes sent or
received.
DISCONNECT
close()
close(): once per connection at end of a

test
FLUSH
None. The Sockets API automatically

sends data without waiting to fill
network buffers.
None.
port_number=AUTO tells
Endpoint 1 to choose the port
for the connection. Otherwise,
specify a port_number.
CONNECT_ACCEPT
(port_number)
Endpoint 1 always provides the
port number for the connection.
datatype)
See Choosing the Datatype
on page 21 for more on the
datatype parameter.
RECEIVE (byte_count,
buffer_size)
See Footnote A below, for information

on the maximum buffer size.
See Footnote B below, for information

Application Scripts
Footnote A: Sockets datagram send buffer size

The maximum value for the buffer_size of the SEND command depends on the platform and network
protocol stack. Most stacks we tested support sending UDP or RTP datagrams of around 65000 bytes.
Exceptions: most Windows 3.1 protocol stacks support 32767, but some dont give any indication of the
maximumfor those stacks, we use 8183. For IPX tests, the maximum value for the buffer size is limited
by the network packet size.
Footnote B: Sockets datagram receive buffer size

When recvfrom() or recv() is used, the endpoint uses a buffer whose size is the maximum value of
buffer_size, so that it can receive any buffer at any time. This is necessary because datagrams can be
received out of sequence; an endpoint must be able to receive a large datagram (such as a retransmitted or
delayed datagram) when only a small one is expected. Although the specified buffer_size is not used with
recvfrom() or recv(), it is used to calculate the window size in numbers of datagrams. Therefore, its
important to use the same value for the RECEIVE buffer_size as for the SEND buffer_size. The
maximum value for the buffer_size of the RECEIVE command depends on the platform and network
protocol stack.
Most stacks we tested support receiving UDP or RTP datagrams of around 65000 bytes. Exceptions: most
Windows 3.1 protocol stacks support 32767, but some dont give any indication of the maximumfor
those stacks, we use 8183. For IPX tests, the maximum value for the buffer size is limited by the network
packet size.
10
Mapping of Script Commands for TLI

The TLI programming interface is used for the IPX and SPX protocols, on NetWare and OS/2. The same port
number is required for all the CONNECT_INITIATE commands in a script.
Script Command
TLI stream (for SPX)
TLI datagram (for IPX)
CONNECT_INITIATE
(port_number)
t_open()
t_bind()
t_connect()
t_open()
t_bind() and t_connect(): once per
connection, per test
t_listen()
t_accept()
None.
Using t_snd(), send the number of

bytes in byte_count, in buffer_size
smaller than the buffer_size. The
Using t_sndudata(), send the number

of bytes in byte_count, in buffer_size
smaller than the buffer_size.
Issue t_rcv() calls in a loop, until the

number of bytes specified in
byte_count have been received, in
received may be smaller than the
buffer_size value. The maximum
buffer_size value is 32767.
Issue t_rcvudata() calls in a loop, until

the number of bytes specified in
byte_count have been received.
CONFIRM_REQUEST
t_rcv()waits to receive the one byte

sent because of the partners
t_rcvudata()waits to receive the one

byte sent because of the partners
CONFIRM_ACKNOWLEDGE
Issue t_snd() to return a one-byte data

record to the partner endpoint which
issued the CONFIRM_REQUEST.
This byte is counted in the summary of
bytes sent or received.
Issue t_sndudata() to return a one-byte

data record to the partner endpoint
which issued the
counted in the summary of bytes sent
or received.
DISCONNECT
t_close()
t_close(): once per connection, at the

end of a test
FLUSH
None.
None.
port_number=AUTO tells
Endpoint 1 to choose the port
for the connection. Otherwise,
specify a port_number.
CONNECT_ACCEPT
(port_number)
Endpoint 1 always provides the
port number for the connection.
datatype)
See Choosing the Datatype
for more on the datatype
parameter.
RECEIVE (byte_count,
buffer_size)
See Footnote C below, for information

See Footnote D below, for information

Application Scripts
11
Footnote C: TLI datagram send buffer size

The maximum value for the buffer_size of the SEND command is limited by the IPX network packet size.
Footnote D: TLI datagram receive buffer size

When t_rcvdata() is used, the endpoint uses a buffer whose size is the maximum value of buffer_size, so
that it can receive any buffer at any time. This is necessary because datagrams can be received out of
sequence; an endpoint has to be able to receive a large datagram (for example, a retransmitted or delayed
datagram) when only a small one was expected. Although the specified buffer_size is not used with
t_rcvudata(), it is used to calculate the window size in numbers of datagrams. Therefore, its important to
use the same value for the RECEIVE buffer_size as for the SEND buffer_size.
The maximum value for the buffer_size of the RECEIVE command is limited by the IPX network packet
size.
DEFAULT Values for the Endpoints

The keyword DEFAULT instructs the endpoint to use the default buffer size for the API of the protocol and
platform on which it is running. The default values, in bytes, are shown in the following table.
Operating
System
APPC
send/recv
TCP
send/recv
SPX
send/recv
UDP
send/recv
IPX
send/recv
RTP
send/recv
MVS
32763/ 32767
32767
n/a
8183
n/a
8180
NetWare
n/a
32767
32767
8183
1391 on v4.x,
537 on v3.12
8180
OS/2
32763/ 32767
32767
32767
8183
537
8180
UNIX (all)
n/a
32767
n/a
8183
n/a
8180
Windows 3.1
n/a
4096/ 32767
n/a
8183
n/a
8180
Windows 95/98
32763/ 32767
4096/ 32767
4096/ 32767
8183
1391
8180
Windows NT
32763/ 32767
32767
32767
8183
1391
8180
12
Application Commands
These are the commands that are applied to an application script to emulate specific characteristics of an
application.
Command
Description
SLEEP (time)
Dont do anything for the time specified in milliseconds. Sleep commands can be
used to emulate application processing time or human delays between transactions.
See Setting Sleep Times on

page 16 for more information.
time is either a constant or a randomly-selected number. If you select a constant

sleep time, you enter a positive integer in the range 0 to 999,999,999. The default
value is the constant 0, which means not to sleep. Alternatively, select a type of
random distribution and the range within which the random sleep times should be
generated.
Not all operating systems can sleep for precise 1 millisecond time periods. For
example, the shortest sleep on NetWare endpoints is 1/18th second, that is, 55
milliseconds. Thus, if youre setting a constant sleep time for a script which will use
NetWare, multiples of 55 are the most efficientdue to the granularity of its clock.
RTP_PAYLOAD_TYPE
Causes the Endpoint 1 to set the payload type field in the RTP packet header to the
specified value.
Streaming scripts have an RTP_PAYLOAD_TYPE command. The payload type
identifies the value of the bit pattern that is set in the RTP header. It does not affect
the type of data that is being sent. If you need to send a specific type of data that is
not provided by one of our .CMP files, you can provide a USERXX.CMP file. All
pre-defined scripts default to the correct value for this variable based on the
application being emulated.
You can select from our predefined values for the type field. We have defined the
most common values for the payload type. See Supported RTP Payload Types on
page 12 for a description each of the payload types you can select for the type value.
Supported RTP Payload Types

The following table describes the RTP payload types supported in this release.
Value
Description
PCMU
This value is the North American M-law variation of Pulse Code

Modulation encoding. This is standardized by the ITU as G.711.
GSM
This value is the Global System for Mobile. This is the de facto standard
for digital cellular in Europe and Asia.
G723
This value is for dual-rate 6.3/5.3-Kbps voice encoding scheme.
PCMA
This value is the European A-law variation of Pulse Code Modulation

encoded. This is standardized by the ITU as G.711.
MPA
This value is MPEG audio.
G729
This value is for voice encoding scheme which produces high-quality in a

low data rate.
H261
This value is the common video codec used with image sizes of 352 x 288
pixels.
MPV
This value is MPEG video.
H263
This value is for common video codec used with communication channels
that are multiples of 64 Kbps and image sizes of 176 x 144.
JPEG
This value is the Joint Photographic Experts Group standard and is used for
encoding and compressing color images.
Application Scripts
13
Program Control Commands

These are the commands that are applied to an application script to control its operation.
Command
Description
LOOP (count)
Repeat this loop count times. count is an integer in the range 1 to

999,999,999. The default value varies, depending where its used in each
script.
In Chariot, scripts use a wide variety of default loop count values, to emulate
repeatedly running an application.
In Pegasus, all default loop counts are set to 1 when the scripts are installed,
to emulate a transaction within an application.
END_LOOP
This marks the end of a loop.
START_TIMER
Marks the beginning of a checkpoint, and resets the transaction count to 1. In

streaming scripts, this command is only used at Endpoint 2, which keeps the
timings and accounts for lost data. Otherwise, timing records are kept at
Endpoint 1, so this command is only used in the Endpoint 1 portion of scripts.
END_TIMER
Marks the end of a checkpoint. Causes a timing record to be built, which

includes the transaction count. In streaming scripts, this command is only used
at Endpoint 2, which keeps the timings and accounts for lost data. Otherwise,
timing records are kept only at Endpoint 1, so this command is only used in the
Endpoint 1 portion of scripts.
INCREMENT_TRANSACTION
Increments the number of transactions per timing record. If transactions are

being counted, count another transaction. This value is reset to 1 each time a
START_TIMER command is executed. Because timing records are kept only
at Endpoint 1, this command is only used in the Endpoint 1 portion of scripts.
Every non-streaming script is required to have one call to the
INCREMENT_TRANSACTION command.
Rules for Scripts

The Script Editor lets you build valid scripts that are capable of running on all endpoints with all protocols.
Weve enforced a set of rules that make it impossible to build a bad script. Heres whats described below:
see Overall Script Rules on page 13 for guidelines that apply to the scripts themselves.
see Command and Parameter Rules on page 15 for guidelines on the commands and parameters within a
script. The rules are organized by command.
see Script Variable Rules on page 16 for a general discussion of restrictions on variables.
Overall Script Rules

Here are general rules that apply to all scripts.
Maximum of 1,300 commands per endpoint or 1,000 SEND and RECEIVE commands per endpoint
No script may exceed 1,300 commands per endpoint (this limit has been raised from a maximum of 150
commands in Chariot 2.1 and Pegasus 1.1). You cannot have more than 1,000 SEND or RECEIVE
commands per script. If you find that you need more than 1,300 commands or 1,000 SEND and
RECEIVE commands per endpoint in one script, you should consider breaking the transaction into more
than one script.
14
Application Script Name is required

Use the Application Script Name field to enter a brief (40 character) description of the script. This
script name is required; it is an important field in Pegasus reportsbe sure to enter descriptive
information.
Do not put multiple sleeps in a row in a script

When creating or modifying scripts, do not put multiple SLEEP commands back to back. There are
several problems that you will encounter in the Script Editor and in exporting these scripts.
Seven required commands

There are seven required commands in a valid script; these show up when you create a new script, and
cannot be deleted. However, there is some flexibility in their placement. For alternate arrangements, open
one of the existing scripts shipped with your software. For example, the FTPGET script has a set of
commands that precede the internal timing loopsyou might want to open FTPGET as the template for a
new script you are creating.
An empty script, containing the necessary commands, looks like this on the Endpoint 1 side:
LOOP
count=number_of_timing_records(50)
START_TIMER
LOOP
count=transactions_per_second(100)
END_LOOP
END_TIMER
END_LOOP
In streaming scripts, you cannot add, delete, or move commands

Streaming scripts emulate applications that require uni-directional flow of data at a specified data rate.
You can only change their parameter values. The parameters that are typically changed are
send_buffer_size and send_data_rate. These scripts contain a single SEND command at Endpoint 1 and a
RECEIVE command at Endpoint 2. There is no LOOP command for transactions.
Since the format of these scripts is fixed, there are no CONFIRM or FLUSH commands in streaming
scripts.
The streaming script template looks like this on the Endpoint 1 side:
RTP_PAYLOAD_TYPE
type = H261
SLEEP
time = initial_delay(0)
CONNECT_INITIATE
port = port_number(AUTO)
LOOP
count = number_of_timing_records(50)
SEND
size = file_size(20000)
buffer = send_buffer_size(1280)
type = send_datatype(NOCOMPRESS)
rate = send_data_rate(100 kbps)
END_LOOP
DISCONNECT
The above script does not show the START_TIMER and END_TIMER commands because these
commands are in the Endpoint 2 portion of streaming scripts.
Application Scripts
15
Command and Parameter Rules

Here are rules related to individual commands and their parameters.
CONNECT and DISCONNECT

Only one connection at a time is allowed in an application script. You are not allowed to have nested
connections, although you can have many connections back-to-back. Endpoint 1 initiates all connections,
so issues the CONNECT_INITIATE command; Endpoint 2 always issues CONNECT_ACCEPT. Each
CONNECT command has a corresponding DISCONNECT in the same loop, at the same loop depth.
The port_number parameter is the same value for both endpoints and for all instances of the CONNECT
commands within a script. This script variable is always named port_number; its value is in the range 1
to 65,535 or the value AUTO.
SEND and RECEIVE

There is maximum of 1,000 SEND commands in a script (this limit has been raised from 30 in Chariot 2.1
and Pegasus 1.1). SEND may only take place inside a connection. The send_size matches the
corresponding receive_size parameter, and is in the range 1 to 999,999,999 bytes, inclusive. The two
endpoints may have different buffer sizes on a corresponding SEND/RECEIVE pair, again, in the range 1
to 999,999,999 bytes, inclusive, or the value DEFAULT. The datatype parameter is selected from one of
the defined data types.
FLUSH
FLUSH can only occur within a connection, after a SEND that has not already been FLUSHed or
CONFIRMed. A FLUSH command is on the same endpoint as the most recent SEND. FLUSH is not
allowed inside a loop after a SEND, such that it could be repeated more times that the SEND.
CONFIRM_REQUEST and CONFIRM_ACKNOWLEDGE

CONFIRM_REQUEST can only occur within a connection, after a SEND that has not already been
CONFIRMed. A CONFIRM_REQUEST command is on the same endpoint as the most recent SEND.
Like FLUSH, CONFIRM commands are not allowed inside a loop after a SEND, such that it could be
repeated more times than the SEND.
START_TIMER, END_TIMER, and INCREMENT_TRANSACTION

In streaming scripts, there is no INCREMENT_TRANSACTION command. The START_TIMER and
END_TIMER commands occur only in Endpoint 2. Otherwise, the START_TIMER, END_TIMER, and
INCREMENT_TRANSACTION commands occur at Endpoint 1, and occur once per script.
START_TIMER has a corresponding END_TIMER later in the script, in the same loop at the same loop
depth. An INCREMENT_TRANSACTION command occurs somewhere between START_TIMER and
END_TIMER, and this INCREMENT_TRANSACTION must be at a greater loop depth than the
START_TIMEREND_TIMER pair (this allows the creation of multiple transactions within a timing
record). START_TIMER and END_TIMER must be inside a loop (to create multiple timing records), and
must be within the outermost loop of a script (see LOOP and END_LOOP, below, for the reason).
LOOP and END_LOOP

Each LOOP has a corresponding END_LOOP. The maximum depth of loop nesting is 10. The outermost
loop of a script must contain all the important parts of the script. This is enforced by forcing
START_TIMER, END_TIMER, and INCREMENT_TRANSACTION to be within this loopthis is done
because the number of iterations in this loop is changed when running a test for a fixed duration (rather
than a fixed number of iterations). The loop count parameter matches on the corresponding endpoints,
and is in the range 1 to 999,999,999 iterations, inclusive.
16
SLEEP
There is no restriction on the placement of SLEEP commands. The sleep time parameter must be a
variable, not a constant, and each value is in the range 0 to 999,999,999 milliseconds, inclusive.
RTP_PAYLOAD_TYPE
The RTP_PAYLOAD_TYPE is present in all streaming scripts. However, if the protocol is UDP or IPX,
this field is ignored.
Script Variable Rules

Script variables are used to allow command parameters to be changed globally within a script. Variables can
be used to control LOOP counts, to define port numbers, to specify the data type for a SEND, and so on.
Each variable has a variable type, depending on its usage as a command parameterthe variable type is
not exposed, per se.
Random variables can be used only for sleep times.
Non-zero integer variables can be used for loop count, send size, or buffer size. Variables used for loop
count may not be used for any SEND parameter, and vice versa.
Integer variables which allow the keyword DEFAULT are used only for buffer size.
The port_number variable can be used only for port numbers. Only one variable of this type is allowed
per script. The script editor maintains this variable as the last entry in the variable list.
The name of the variable must be unique within a script, and not contain spaces.
The Default value field lets you specify the initial value for the variable, when the script is installed. The
value entered should allow the script to behave as expected without modification. The field will accept numbers
to 999,999,999. On some variable types, such as the buffer size on SEND and RECEIVE, you can use other
values, such as the term DEFAULT or AUTO. The DEFAULT value depends on the network protocol and
the endpoints you are using. AUTO, when entered for the port_number variable, specifies that Endpoint 1
should dynamically choose the port number to use in the test.
In contrast, you may be familiar with the Current value field in tests. Changes to the Current value apply
only to a specific endpoint connection. The Current value is saved with a connection, not with a script.
Default value is the value that is saved with a script.
The type of variable used for the SLEEP command allows only five values: Constant Value, Exponential,
Normal, Poisson, and Uniform Distribution. For a Constant Value, one field is presented for the value. For a
distribution, two fields allow you to enter the range. All values are in milliseconds. For more information, see
Setting Sleep Times below.
The Variable comment and Variable help text allow you to enter details about this variable and how to use it in
the script.
Setting Sleep Times

The time parameter value on the SLEEP command lets you emulate delays by users or processing time at one
of the computers. Before the next script command is executed, the endpoint sleeps for the number of
milliseconds specified here. The sleep does not consume CPU cycles; it is only simulating a delay, not the
CPU or disk overhead that a real application might use.
Application Scripts
17
The location of the SLEEP command in the script is important. If the SLEEP command is before the timing
loop, the SLEEP does not effect the data that is sent and received. This means that timing records do not
reflect the impact that the SLEEP command had on the data. If the SLEEP command is within the timing
loop, the results include the effects that the SLEEP command had on the sending and receiving of data.
The Current Value field lets you change the amount of time to sleep. Scripts have their delay values set to a
default Constant value of 0, which means that endpoints execute scripts as quickly as possible.
The script variable initial_delay is different from the other sleep variables. The longest allowable time for
initial_delay is 90 minutes, that is 5,400,000 milliseconds. Longer values cause Endpoint 2 to time out, and
the connection will fail.
A script can sleep for a constant duration, or the sleep time can be randomly distributed using one of four
distributions. When choosing a random distribution, be sure to set upper and lower limits that provide
meaningful results. Choose upper and lower limits that are far enough apart to provide the endpoints an
opportunity to create a range of random sleep times. If the limits are too close together, you will not see the
effects of random sleeps. For example, a lower limit of 5 milliseconds and an upper limit of 7 milliseconds
will not provide enough variance for interesting random sleeps.
Guidelines for how to determine the values for the upper and lower limits depend on the purpose of the specific
SLEEP command.
If you are using a SLEEP command for an initial_delay, a lower limit of 0 and an upper limit of 1000 (that
is, 1 second) will emulate the random effects of a large network.
If you are using a SLEEP command for a delay_before_responding, the values should mimic the activity
that you are emulating. If you are using this parameter to control throughput, use a narrow range between the
upper and lower limits and relatively small values. The upper limits should not exceed 100, since large values
cause measured throughput to reduce rapidly.
Another use of the delay_before_responding is to emulate the delay time on a server or client-server
application. In this case, a reasonable lower limit is 5. You should use high upper limits. For example, if
you are emulating a three-tiered application, the upper limit should be several thousand milliseconds.
If you are using a SLEEP command for a transaction_delay, the values should emulate the rate that
transactions are happening based on the number of users. You should determine the typical delay between a
users transactions and convert the amount of time to milliseconds.
For example, if you are emulating users transferring files, and the average user transfers a file every 20
minutes, there is a typical delay of 20 minutes. 20 minutes converted to milliseconds is 1,200,000.
Reduce this time by the number of users. If you have 10 users, reduce the 1,200,000 delay time to 120,000
milliseconds. You would then use this time to determine the upper and lower limits for SLEEP. For the
lower limits, reduce this time by 10%. In this example, use a lower limit of 120,000. For the upper limit,
increase this time by 10%. In this example, use an upper limit of 12,000,000.
As a general rule, if you are emulating a large number of users, use small values for the upper and lower
distributions. If you are emulating a small number of users, you should use large values.
The four distributions for random sleep time are Uniform, Normal, Poisson, or Exponential. If you choose one
of these random distributions, you also must select the upper and lower limits for the random times that are
generated.
18
Uniform
The distribution of sleep times between the upper and lower limit is completely uniform. Any number
within the upper and lower limits are as likely to be used for the sleep time as any other number. If you
plot the sleep times against the number of occurrences, the graph should be a flat horizontal line.
Normal
The distribution of sleep times between the upper and lower limits is a normal, or bell-curved, distribution.
If you plot the sleep times against the number of occurrences, the graph should be a bell curve.
The Marsaglia-Bray algorithm is used to generate the normal distribution. The average value of the
distribution is determined from the upper and lower limit. In a normal distribution, most values occur
within +/-3 standard deviations with respect to the average. The standard deviation is also calculated from
the upper and lower limits, as no value exceeds those limits.
Poisson
The distribution of sleep times between the upper and lower limit is a Poisson distribution. If you plot the
sleep times against the number of occurrences, the graph should look like a Poisson distribution. A typical
use of Poisson distribution is to emulate data inter-arrival rates
The incomplete gamma function is used to generate the Poisson distribution. The average value of the
distribution is determined from the upper and lower limit. In a Poisson distribution, most values occur
within +/-3 standard deviations with respect to the average. The standard deviation is also calculated from
the upper and lower limits, as no value will exceed those limits.
Application Scripts
19
This graph is based on an average and standard deviation. 99% of all values on the graph should be
within +/-3 times the standard deviation. An endpoint calculates the standard deviation by dividing the
difference of the upper and lower limits by six.
Exponential
The distribution of sleep times between the upper and lower limit is an exponential distribution. In other
words, if you plot the sleep times against the number of occurrences, the graphs maximum should be at
the upper limit and minimum should be at the lower limit.
The lower limit is where the asymptote occurs. The exponential distribution centers around the average of
the upper and lower limit. This should be the average of the distribution. An endpoint uses the average to
calculate the distribution and makes sure that no values exceed the upper limit.
Setting the Send Data Rate

You can send data at a specific rate over all supported protocols. The send_data_rate script variable controls
the rate the data is sent over the protocol. You may want to specify a specific data rate when generating a
constant amount of network traffic or emulating multiple slower links across a single higher speed link. The
data rate calculated by the endpoint is based on the amount of data that is specified. Because this rate does not
include protocol and link-layer data lengths, the actual bandwidth consumed in the network is slightly higher
than the send_data_rate you specify.
20
Enter a send_data_rate or select one of the following rates:
28.8 kbps (modem)

33.3 kbps (modem)
56 kbps (modem)
64 kbps (fractional T1)
128 kbps (fractional T1/ISDN)
1.544 Mbps (T1)
2.048 Mbps (E1)
8.448 Mbps (E2)
10 Mbps (Ethernet)
44.736 Mbps (T3)
155.52 Mbps (OC-3)
UNLIMITED
You can modify the send_data_rate in the script you want to use. The endpoint sending the data calculates
how fast to send the data and then sends the data continuously over the timing record. The total amount of
data per timing record is divided by the buffer size to get the amount of data for each send.
For streaming tests containing multicast groups, the Endpoint 2 or receiver calculates the throughput in the
timing record. You may notice that the throughput is a slightly less than the rate you specified.
Here are some tips for achieving a constant send data rate:
Send a lot of data in relationship to the buffer size and rate. For example, if you are using a buffer size of
8K, setting a send_data_rate of 1 million bytes will give you a more consistent data rate. The faster the rate,
the more data you need to send to achieve a constant rate. Be aware that if you are using the default buffer
size, the default buffer size varies based on network protocol and operating system.
When trying to achieve a constant send rate, some scripts are better than others. Scripts that have
connects within a timing records are not good for trying to attain a steady send data rate. Scripts that contain
only sends within a timing record are better for achieving a steady send data rate.
If you are running a streaming test containing multicast groups, use the send_data_rate UNLIMITED with
caution. UNLIMITED sends data as fast as possible. Using the rate can possibly flood the network switches
and may adversely affect network performance.
The timers in different endpoint platforms have different resolution. The resolution affects the accuracy
we can achieve with the send data rate. Some experimentation may be necessary to find the best send data rate
to use for your endpoint platform.
As you increase the rate at which data is sent, you may need to increase the amount of data being sent.
The more data sent in the timing record, the more opportunity the endpoint has to smooth out the rate. For
example, when sending at 10Mbps, you may need to send 1 million bytes of data per timing record to achieve a
constant rate. The amount of data may need to be increased proportionately as the rate increases. Some
experimentation may be necessary.
Application Scripts
Choosing the Datatype on the SEND Command

The third parameter of the SEND command lets you choose the contents of the data. When editing this
variable, choose one of the following values from the Current Value pulldown:
send_datatype
Description
ZEROS
The data contains all hex zeros. This is the simplest data for the endpoints to
generate. Data consisting of all zeros is easy to compress, by even the most primitive
compression techniques.
NOCOMPRESS
Each byte of data is randomly selected from among the 256 possible hexadecimal
values. Since theres usually no pattern to the sequence of characters, buffers full of
NOCOMPRESS data are difficult to compress effectively. The data generation is
done once during test setup, and does not increase the CPU usage at the endpoints.
named .CMP files
Choose one of the following predefined data files, representing typical types of
computer data, from the Calgary Corpus (see
http://links.uwaterloo.ca/calgary.corpus.html for more information).
BIB.CMP
text file (bibliography)
BOOK1.CMP
text file (book 1)
BOOK2.CMP
text file (book 2)
GEO.CMP
binary file (geophysical data)
LENA.CMP
binary graphic file (GIF format)
NEWS.CMP
text file (newsgroup text)
PAPER1.CMP
text file (paper 1)
PAPER2.CMP
text file (paper 2)
PIC.CMP
binary file (CCITT fax test)
PROGC.CMP
text file (C program source)
PROGL.CMP
text file (LISP program source)
PROGP.CMP
text file (Pascal program source)
TRANS.CMP
text file (terminal session) Listings of Application Scripts
USER01.CMP through
USER10.CMP
Data is read from the file CMPFILES\USERxx.CMP, which you put at the endpoint
computers. You may put anything you choose in these files. Up to 10 user files can
be created to contain any data desired. Files with the same name must contain the
same data on each endpoint where they are used if data validation is used.
21
22
Listing of Application Scripts
23
Listings of Application Scripts

This section describes the application scripts shipped with your product, along with their commands, and their
script variables. It lists the default value for each script variable. For a complete listing of all Ganymede
Software Application Scripts and to download the latest version of a script, see the Ganymede Software
Application Script Library at http://www.ganymede.com/download/scripts/. This site is a comprehensive
listing of the latest versions of all Ganymede Software scripts. The listing of scripts in this manual is just a
representation of some of the scripts available.
In Chariot, scripts use a wide variety of default loop count values, to emulate repeatedly running an
application. The default transactions_per_record values differ between long-and-short-connection versions
of the same script (such as CREDITL and CREDITS). This is to keep the run time of the two scripts about the
same, for example, for a few seconds on a 10Mbps Ethernet LAN.
In Pegasus, all default loop counts are set to 1 when the scripts are installed, to emulate a single use of an
application.
The script file name is shown for each script. These are the 8.3 names (eight characters followed by a threecharacter extension) by which the scripts can be opened and saved in Chariot and the Script Editor. Script file
names are also remembered in the Pegasus database when it is initialized or when scripts are imported. These
script file names are then used when the script is exported.
24
BKWBSIGN Script (BackWeb Sign-up and InfoPak Download)

This script represents subscribing to and downloading the contents of a new BackWeb channel. The average
request is 300 bytes, and the content response is 3,000 bytes.
For more information on BackWeb, see the BackWeb Technologies Web site at http://www.backweb.com.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
number_of_timing_records=50
START_TIMER
LOOP
transactions_per_record=1
LOOP
30
CONNECT_INITIATE
port_number=AUTO
SEND
size_of_record_to_send=300
control_datatype=trans.cmp
send_data_rate=UNLIMITED
RECEIVE
file_size=3000
receive_buffer_size=DEFAULT
DISCONNECT
END_LOOP
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
LOOP
30
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
delay_before_responding=0
SEND
file_size=3000
send_buffer_size=DEFAULT
send_datatype=NOCOMPRESS
DISCONNECT
END_LOOP
END_LOOP
END_LOOP
Variable Name
Chariot Default
Pegasus Default
25
Description
initial_delay
Pause before the first

transaction
number_of_timing_records
50
How many timing records to

generate
Transactions per timing record
size_of_record_to_send
300
300
Amount of data to be sent
file_size
3,000
3,000
How many bytes in the

transferred file
send_buffer_size
DEFAULT
DEFAULT
How many bytes of data in each

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
delay_before_responding
Milliseconds to wait before

responding
transaction_delay
Milliseconds to pause
send_datatype
NOCOMPRESS
NOCOMPRESS
What type of data to send
control_datatype
trans.cmp
trans.cmp
What type of control data to

send
send_data_rate
UNLIMITED
UNLIMITED
How fast to send data
port_number
AUTO
AUTO
What port to use between

endpoints
26
BKWBUPDT Script (BackWeb Update)

This script represents an update of an existing BackWeb channel. The average request is 400 bytes, and the
average content response is 11,000 bytes.
For more information on BackWeb, see the BackWeb Technologies Web site at http://www.backweb.com.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
LOOP
10
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
file_size=11000
DISCONNECT
END_LOOP
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
LOOP
10
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
SEND
file_size=11000
DISCONNECT
END_LOOP
END_LOOP
END_LOOP
Variable Name
Chariot Default
Pegasus Default
27
Description
initial_delay

transaction
50

generate
400
400
file_size
11,000
11,000

transferred file
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE

responding
transaction_delay
send_datatype
NOCOMPRESS
NOCOMPRESS
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
28
CASTDL Script (Castanet Channel Download)

This script emulates the downloading of channels. Each timing record represents the download of a single
channel. It works like the download of the Tuner (since both are downloading a Java application)the
difference is the amount of data thats sent and received. Weve chosen 500,000 bytes as the default file_size;
this value depends on the channel being downloaded.
For more information on the Castanet Tuner, see the Marimba Web site at http://www.marimba.com.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
control_buffer_size=DEFAULT
RECEIVE
reply_size=2000
DISCONNECT
CONNECT_INITIATE
port_number=AUTO
SEND
file_control_size=1500
RECEIVE
file_size=500000
DISCONNECT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
SEND
reply_size=2000
DISCONNECT
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
SEND
file_size=500000
DISCONNECT
END_LOOP
END_LOOP
Variable Name
Chariot Default
Pegasus Default
29
Description
initial_delay

transaction
50

generate
300
300
control_buffer_size
DEFAULT
DEFAULT
Buffer size for control flows
reply_size
2,000
2,000

responding
file_control_size
1,500
1,500
How many bytes are in the

control flows
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
control_datatype
trans.cmp
trans.cmp

send
file_size
500,000
500,000

transferred file
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
transaction_delay
port_number
AUTO
AUTO

endpoints
30
CASTINIT Script (Castanet Initial Run)

This script represents a user running the Castanet Tuner the first time. The Tuner, when run, checks if its up
to date, by querying the Marimba home base. Next, it downloads the part of the Java-based Tuner thats not up
to date.
There are two connections: the first representing a query; the other representing the Tuner download (which is
generally a lot of data).
For more information on the Castanet Tuner, see the Marimba Web site at http://www.marimba.com.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
reply_size=2000
DISCONNECT
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
file_size=1350000
DISCONNECT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
SEND
reply_size=2000
DISCONNECT
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
SEND
file_size=1350000
DISCONNECT
END_LOOP
END_LOOP
Variable Name
Chariot Default
Pegasus Default
31
Description
initial_delay

transaction
50

generate
300
300
control_buffer_size
DEFAULT
DEFAULT
reply_size
2,000
2,000

responding
file_control_size
1,500
1,500

control flows
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
control_datatype
trans.cmp
trans.cmp

send
file_size
1,350,000
1,350,000

transferred file
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
transaction_delay
port_number
AUTO
AUTO

endpoints
32
CONN Script (Connectivity)

This script quickly checks the connectivity between a pair of endpoints. It is used extensively in Pegasus, when
verifying the current end-to-end connection between endpoint programs.
A Pegasus connection that uses this application script cannot have a threshold. It also does not return
performance results, but does return connectivity information. There are two asterisks next to this script name
in Pegasus, indicating that is a connectivity-only script. If you copy the script to a different name, the new
script will be similarly limited, and will have two asterisks next to its name.
Endpoint 1
----------
Endpoint 2
----------
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
SEND
send_datatype=ZEROS
RECEIVE
CONNECT_ACCEPT
port_number=AUTO
LOOP
END_LOOP
END_TIMER
END_LOOP
DISCONNECT
Variable Name
LOOP
RECEIVE
SEND
send_datatype=ZEROS
END_LOOP
END_LOOP
DISCONNECT
Chariot Default
Pegasus Default
Description

generate
10
10
send_buffer_size
DEFAULT
DEFAULT

SEND
send_datatype
ZEROS
ZEROS
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
CREDITL Script (Credit Check, long connection)

This is the version of the Credit Check transaction that uses a long connection.
This is a quick transaction that emulates a series of credit approvals. A record is sent from Endpoint 1.
Endpoint 2 receives the record and sends back a confirmation.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
SEND
CONFIRM_REQUEST
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
RECEIVE
SLEEP
CONFIRM_ACKNOWLEDGE
END_LOOP
END_LOOP
DISCONNECT
33
34
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
50
100
100
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
transaction_delay

responding
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
CREDITS Script (Credit Check, short connections)

This is the version of the Credit Check transaction that uses short connections.
This is a quick transaction that emulates a series of credit approvals. A record is sent from Endpoint 1.
Endpoint 2 receives the record and sends back a confirmation.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
CONFIRM_REQUEST
DISCONNECT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
CONFIRM_ACKNOWLEDGE
DISCONNECT
END_LOOP
END_LOOP
35
36
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
25
100
100
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
transaction_delay

responding
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
37
DBASEL Script (Database Update, long connection)

This is the version of the Database Update transaction that uses a long connection.
This is the most complex of the benchmark scripts. It emulates a program that requests a record from
Endpoint 2, gets it, updates it and sends it back. Lastly, Endpoint 1 receives a confirmation that the update
was completed. (This script can be described as an Inquiry followed by a Credit Check.).
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
SEND
RECEIVE
reply_size=100
reply_size=100
SLEEP
user_delay=0
SEND
update_size=100
update_size=100
CONFIRM_REQUEST
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
RECEIVE
SLEEP
SEND
reply_size=100
reply_size=100
RECEIVE
update_size=100
update_size=100
CONFIRM_ACKNOWLEDGE
END_LOOP
END_LOOP
DISCONNECT
38
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
25
100
100
reply_size
100
100
How many bytes to send in the

reply
update_size
100
100

update

responding
transaction_delay
user_delay
Pause before answering
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
39
DBASES Script (Database Update, short connections)

This is the version of the Database Update transaction that uses short connections.
This is the most complex of the benchmark scripts. It emulates a program that requests a record from
Endpoint 2, gets it, updates it and sends it back. Lastly, Endpoint 1 receives a confirmation that the update
was completed. (This script can be described as an Inquiry followed by a Credit Check.).
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
reply_size=100
reply_size=100
SLEEP
user_delay=0
SEND
update_size=100
update_size=100
CONFIRM_REQUEST
DISCONNECT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
SEND
reply_size=100
reply_size=100
RECEIVE
update_size=100
update_size=100
CONFIRM_ACKNOWLEDGE
DISCONNECT
END_LOOP
END_LOOP
40
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
10
100
100
reply_size
100
100

reply
update_size
100
100

update

responding
transaction_delay
user_delay
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
41
FILERCVL Script (File Receive, long connection)

This is the version of the File Receive transaction that uses a long connection.
This transaction emulates requesting a file and getting it back. The request from Endpoint 1 defaults to 100
bytes. The default file size is 100,000 bytes.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
SEND
RECEIVE
file_size=100000
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
RECEIVE
SEND
file_size=100000
END_LOOP
END_LOOP
DISCONNECT
42
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
100

generate
100
100
file_size
100,000
100,000

transferred file
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
transaction_delay
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
43
FILERCVS Script (File Receive, short connections)

This is the version of the File Receive transaction that uses short connections.
This transaction emulates requesting a file and getting it back. The request from Endpoint 1 defaults to 100
bytes. The default file size is 100,000 bytes.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
file_size=100000
DISCONNECT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SEND
file_size=100000
DISCONNECT
END_LOOP
END_LOOP
44
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
100

generate
100
100
file_size
100,000
100,000

transferred file
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
transaction_delay
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
45
FILESNDL Script (File Send, long connection)

This is the version of the File Send transaction that uses a long connection.
This transaction emulates sending a file from Endpoint 1 to Endpoint 2, and getting a confirmation back.
Endpoint 1
----------
Endpoint 2
----------
SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
SEND
file_size=100000
CONFIRM_REQUEST
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Variable Name
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
RECEIVE
file_size=100000
CONFIRM_ACKNOWLEDGE
END_LOOP
END_LOOP
DISCONNECT
Chariot Default
Pegasus Default
Description
initial_delay

transaction
100

generate
file_size
100,000
100,000

transferred file
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
transaction_delay
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
46
FILESNDS Script (File Send, short connections)

This is the version of the File Send transaction that uses short connections.
This transaction emulates sending a file from Endpoint 1 to Endpoint 2, and getting a confirmation back.
Endpoint 1
----------
Endpoint 2
----------
SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
file_size=100000
CONFIRM_REQUEST
DISCONNECT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Variable Name
LOOP
LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
file_size=100000
CONFIRM_ACKNOWLEDGE
DISCONNECT
END_LOOP
END_LOOP
Chariot Default
Pegasus Default
Description
initial_delay

transaction
100

generate
file_size
100,000
100,000

transferred file
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
transaction_delay
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
47
FTPGET Script (FTP get files)

This script emulates receiving a file at Endpoint 1 from Endpoint 2, using TCP/IPs FTP application (the FTP
get function).
There are three sections in this script, each with its own connection. The first section emulates a logon by
Endpoint 1 to Endpoint 2. The second, timed section emulates the transfer of a 100,000 byte files. Only this
middle section is timed. The third section emulates a user logging off. Most of the variables in the first and
third sections are hardcoded; these sections are components of the total network traffic a real FTP creates, but
are not in the timed loop.
1.
In the first section, Endpoint 1 receives the request for a logon, and replies by sending a user name. It
then receives a request for a password, and replies by sending a password. Finally, it receives the
acknowledgment that the logon is successful.
2.
In the inner loop of the second section, Endpoint 1 sends its port, and receives an okay in reply. It then
sends a filename, and receives the opening message in reply. Finally, it receives the file it requested. Its
outer loop allows you to receive multiple files, like the FTP mget command.
3.
In the third section, Endpoint 1 sends the message that the transfer is complete, and receives an
acknowledgment in reply.
The script variable named number_of_repetitions lets you repeat the entire FTP script, including the logon
and logoff processingwhich isnt timed. For the best performance measurements, leave this variable set to
its default of 1. If you change this variable (for example, for stress testing), the number of received timing
records will be a multiple of your number_of_timing_records variable.
The FTPGET and FTPPUT scripts are designed to emulate ALL of the activity that surrounds the actual file
transfer portion of an FTP transaction. When doing FTP, an individual Get or Put command does just the
inner loop of this scriptsending a chunk of data in one direction. This is easy to see by examining the
FTPGET or FTPPUT scripts. Notice that, after the timer has been started, the script executes a connection
sequence (4 flows), then 4 more flows, before the actual file transfer is even begun. If your objective is to find
the maximum throughput across a link, these scripts are NOT a good match for you.
A better choice is to use the script named PACKETLR, and compare it to an FTP program doing a Get
command. (You should never use PACKETL or the Put command to measure throughput.) Even after
following this advice, you may see different results due to an FTP programs use of special parameters when
calling the program interface, which cause a different window size to be used by the FTP program.
The well-known port number for FTP data flows in TCP and UDP is 20; port number 21 is used for FTP
control flows.
Note when using IPX:
In the inner loop of this script, the send_buffer_size and receive_buffer_size is set to 4,096, rather than
DEFAULTto emulate the real application. With IPX, the DEFAULT value is less than 4,096 bytes on
all endpoints. To run this script successfully with IPX, you must change the send_buffer_size variable to a
number less than or equal to the DEFAULT value (which is either 1,391 or 537). See DEFAULT Values
for the Endpoints for a table of the byte sizes used for buffers at each endpoint.
48
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
number_of_repetitions=1
CONNECT_INITIATE
port_number=AUTO
RECEIVE
login_size=15
SLEEP
user_delay=0
SEND
login_size=15
RECEIVE
login_size=15
SLEEP
user_delay=0
SEND
login_size=15
RECEIVE
200
DISCONNECT
LOOP
START_TIMER
LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
SEND
RECEIVE
SLEEP
Endpoint 2
----------
LOOP
CONNECT_ACCEPT
port_number=AUTO
SEND
login_size=15
RECEIVE
login_size=15
SEND
login_size=15
RECEIVE
login_size=15
SEND
200
200
DISCONNECT
LOOP
LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SEND
RECEIVE
SEND
SEND
send_buffer_size=4096
RECEIVE
DISCONNECT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
6
6
RECEIVE
25
DISCONNECT
END_LOOP
RECEIVE
receive_buffer_size=4096
SEND
DISCONNECT
END_LOOP
END_LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
6
SEND
25
25
DISCONNECT
END_LOOP
49
50
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
number_of_repetitions
How many times to repeat the

script
100

generate
100,000
100,000
user_delay
transaction_delay

responding
file_control_size
30
30

control flows
login_size
15
15

login flows
control_buffer_size
DEFAULT
DEFAULT
send_buffer_size
4,096
4,096

SEND
receive_buffer_size
4,096
4,096

RECEIVE
send_datatype
NOCOMPRESS
NOCOMPRESS
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
51
FTPPUT Script (FTP put files)

This script emulates sending a file from Endpoint 1 to Endpoint 2, using TCP/IPs FTP application (the FTP
put function).
There are three sections in this script, each with its own connection. The first section emulates a logon by
Endpoint 1 to Endpoint 2. The second, timed section emulates the transfer of 100,000 byte files. Only this
middle section is timed. The third section emulates a user logging off. Most of the variables in the first and
third sections are hardcoded; these sections are components of the total network traffic a real FTP creates, but
are not in the timed loop.
1.
then receives a request for a password, and replies by sending a password. Finally, it receives the
acknowledgment that the logon is successful.
2.
In the inner loop of the second section, Endpoint 1 sends its port, and receives an okay in reply. It then
sends a filename, and receives the opening message in reply. Finally, it sends the file to Endpoint 2. Its
outer loop allows you to send multiple files, like the FTP mput command.
3.
The script variable named number_of_repetitions lets you repeat the entire FTP script, including the logon
and logoff processingwhich isnt timed. For the best performance measurements, leave this variable set to
its default of 1. If you change this variable (for example, for stress testing), the number of received timing
records will be a multiple of your number_of_timing_records variable.
The FTPGET and FTPPUT scripts are designed to emulate ALL of the activity that surrounds the actual file
transfer portion of an FTP transaction. When doing FTP, an individual Get or Put command does just the
inner loop of this scriptsending a chunk of data in one direction. This is easy to see by examining the
FTPGET or FTPPUT scripts. Notice that, after the timer has been started, the script executes a connection
sequence (4 flows), then 4 more flows, before the actual file transfer is even begun. If your objective is to find
the maximum throughput across a link, these scripts are NOT a good match for you.
A better choice is to use the script named PACKETLR, and compare it to an FTP program doing a Get
command. (You should never use PACKETL or the Put command to measure throughput.) Even after
following this advice, you may see different results due to an FTP programs use of special parameters when
calling the program interface, which cause a different window size to be used by the FTP program.
The well-known port number for FTP data flows in TCP and UDP is 20; port number 21 is used for FTP
control flows.
In the inner loop of this script, the send_buffer_size and receive_buffer_size is set to 4,096, rather than
DEFAULTto emulate the real application. With IPX, the DEFAULT value is less than 4,096 bytes on
all endpoints. To run this script successfully with IPX, you must change the send_buffer_size variable to a
number less than or equal to the DEFAULT value (which is either 1,391 or 537). See DEFAULT Values
for the Endpoints on page 11 for a table of the byte sizes used for buffers at each endpoint.
52
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
CONNECT_INITIATE
port_number=AUTO
RECEIVE
login_size=15
SLEEP
user_delay=0
SEND
login_size=15
RECEIVE
login_size=15
SLEEP
user_delay=0
SEND
login_size=15
RECEIVE
200
DISCONNECT
LOOP
START_TIMER
LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
SEND
RECEIVE
SLEEP
Endpoint 2
----------
LOOP
CONNECT_ACCEPT
port_number=AUTO
SEND
login_size=15
RECEIVE
login_size=15
SEND
login_size=15
RECEIVE
login_size=15
SEND
200
200
DISCONNECT
LOOP
LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SEND
RECEIVE
SEND
SEND
RECEIVE
DISCONNECT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
6
6
RECEIVE
25
DISCONNECT
END_LOOP
RECEIVE
SEND
DISCONNECT
END_LOOP
END_LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
6
SEND
25
25
DISCONNECT
END_LOOP
53
54
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
number_of_repetitions
How many times to repeat the

script
100

generate
100,000
100,000
user_delay
transaction_delay

responding
file_control_size
30
30

control flows
login_size
15
15

login flows
control_buffer_size
DEFAULT
DEFAULT
send_buffer_size
4,096
4,096

SEND
receive_buffer_size
4,096
4,096

RECEIVE
send_datatype
NOCOMPRESS
NOCOMPRESS
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
55
HDLNINIT Script (Headliner Initial Load)

This script can be used to emulate the initial run of Headliner, using its default settings. 5 channels are
automatically selected. Besides the channel contents, the list of channels is also downloaded.
The connections arent all serialized, so the set of connections needs to be spread over a set of endpoint
connections. The concurrency comes about, in part, because each channel is downloaded independently of the
others.
The average request is 300 bytes. The average response of content is 15,000 bytes.
Headliner was created by Lanacom, which was acquired by BackWeb Technologies in July 1997. For more
information, see the BackWeb Web site at http://www.backweb.com.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
LOOP
10
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
file_size=15000
DISCONNECT
END_LOOP
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
LOOP
10
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
SEND
file_size=15000
DISCONNECT
END_LOOP
END_LOOP
END_LOOP
56
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
300
300
file_size
15,000
15,000

transferred file
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE

responding
transaction_delay
send_datatype
NOCOMPRESS
NOCOMPRESS
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
57
HDLNUPDT Script (Headliner Subsequent Update)

This script represents updates of a Headliner channel. This Headliner update script differs from the initial run
in that the list of channels is not downloaded again. Note that when new channels become available, the list of
them will be downloadedhowever, thats not reflected here because it doesnt occur at a known time.
Headliner was created by Lanacom, which was acquired by BackWeb Technologies in July 1997. For more
information, see the BackWeb Web site at http://www.backweb.com.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
file_size=15000
DISCONNECT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
SEND
file_size=15000
DISCONNECT
END_LOOP
END_LOOP
58
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
300
300
file_size
15,000
15,000

transferred file
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE

responding
transaction_delay
send_datatype
NOCOMPRESS
NOCOMPRESS
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
59
HTTPGIF Script (Web GIF download)

This script emulates the traffic of an HTTP GIF (graphical image file) transfer. Endpoint 1, as the client,
requests a GIF file from Endpoint 2, as the Web server. The default file size is 10,000 bytes; the default data
type for the file is LENA.CMP.
The receive buffer size is set to DEFAULT, to allow compatibility with all operating systems and protocols. A
receive buffer size of 31,744 is commonly used by todays Web browsers and servers.
The well-known port number for HTTP flows in TCP and UDP is 80.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
file_size=10000
DISCONNECT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
SEND
file_size=10000
send_datatype=lena.cmp
DISCONNECT
END_LOOP
END_LOOP
60
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
10
300
300
file_size
10,000
10,000

transferred file
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE

responding
transaction_delay
send_datatype
lena.cmp
lena.cmp
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
61
HTTPTEXT Script (Web text download)

This script emulates the traffic of an HTTP text transfer. Endpoint 1, as the client, requests a file from
Endpoint 2, as the Web server. The default values for the buffer sizes reflects those commonly found on
todays Web browsers and servers. The default file size is 1,000 bytes; the default data type for the file is
NEWS.CMP.
The FILERCVS Script (File Receive, short connections) on page 43 is structured similarly, but with different
script variable defaults.
The well-known port number for HTTP flows in TCP and UDP is 80.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
file_size=1000
DISCONNECT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
SEND
file_size=1000
send_datatype=news.cmp
DISCONNECT
END_LOOP
END_LOOP
62
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
10
300
300
file_size
1,000
1,000

transferred file
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE

responding
transaction_delay
send_datatype
news.cmp
news.cmp
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
63
INQUIRYL Script (Inquiry, long connection)

This is the version of the Inquiry transaction that uses a long connection.
This is a typical client/server transaction. Endpoint 1 sends a request to Endpoint 2, which sends a reply back.
The script variables let you add delays, and change the send and receive buffer sizes.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
SEND
inquiry_send_buffer=DEFAULT
RECEIVE
reply_size=100
reply_receive_buffer=DEFAULT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
RECEIVE
inquiry_receive_buffer=DEFAULT
SLEEP
SEND
reply_size=100
reply_send_buffer=DEFAULT
END_LOOP
END_LOOP
DISCONNECT
64
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
50
100
100
inquiry_send_buffer
DEFAULT
DEFAULT

SEND
inquiry_receive_buffer
DEFAULT
DEFAULT

RECEIVE

responding
reply_size
100
100
reply_send_buffer
DEFAULT
DEFAULT

SEND
reply_receive_buffer
DEFAULT
DEFAULT

RECEIVE
transaction_delay
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
65
INQUIRYS Script (Inquiry, short connections)

This is the version of the Inquiry transaction that uses short connections.
This is a typical client/server transaction. Endpoint 1 sends a request to Endpoint 2, which sends a reply back.
The script variables let you add delays, and change the send and receive buffer sizes.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
reply_size=100
DISCONNECT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
SEND
reply_size=100
DISCONNECT
END_LOOP
END_LOOP
66
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
25
100
100
inquiry_send_buffer
DEFAULT
DEFAULT

SEND
DEFAULT
DEFAULT

RECEIVE

responding
reply_size
100
100
reply_send_buffer
DEFAULT
DEFAULT

SEND
DEFAULT
DEFAULT

RECEIVE
transaction_delay
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
67
IPTVA Script (Cisco IP/TV, MPEG audio stream)

This streaming script emulates a Cisco IP/TV Media Server, streaming an audio file over a fast Ethernet link.
The file is encoded as MPEG, and contains both audio and video elements.
This script is designed to run with the related video script to produce a combined T1 data rate. The
send_data_rate variable of this audio portion defaults to an average rate of 93 kbps.
The type value for the RTP_PAYLOAD_TYPE is set to MPA, for MPEG Audio.
For more information, see the Cisco Systems Web site at http://www.cisco.com/iptv.
In the inner loop of this script, the send_buffer_size is set to 1,278, rather than DEFAULTto emulate the
real application. With IPX, the DEFAULT value is less than 1,278 bytes on some endpoints. To run this
script successfully with IPX, you must change the send_buffer_size variable to a number less than or equal
to the DEFAULT value (which is either 1,391 or 537). See DEFAULT Values for the Endpoints on
page 11 for a table of the byte sizes used for buffers at each endpoint.
The discussion of Streaming Scripts on page 5 provides details on endpoint operation and the performance
statistics that are collected when running this script.
Endpoint 1
---------RTP_PAYLOAD_TYPE
MPA
SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
SEND
file_size=25560
send_data_rate=93 kbps
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
START_TIMER
RECEIVE
file_size=25560
END_TIMER
END_LOOP
DISCONNECT
68
Variable Name
Chariot Default
Description
initial_delay
Pause before the

first transaction
100
How many timing

records to
generate
file_size
25,560
How many bytes

in the transferred
file
send_buffer_size
1,278
How many bytes

of data in each
SEND
receive_buffer_size
DEFAULT
How many bytes

of data in each
RECEIVE
send_datatype
NOCOMPRESS
What type of data

to send
send_data_rate
93.0 kbps
How fast to send

data
port_number
AUTO
What port to use

between endpoints
69
IPTVV Script (Cisco IP/TV, MPEG video stream)

This streaming script emulates a Cisco IP/TV Media Server, streaming a video file over a fast Ethernet link.
The file is encoded as MPEG, and contains both audio and video elements.
This script is designed to run with the related audio script to produce a combined T1 data rate. The
send_data_rate variable of this video portion defaults to an average rate of 1,451 kbps.
The type value for the RTP_PAYLOAD_TYPE is set to MPV for MPEG Video.
In the inner loop of this script, the send_buffer_size is set to 1,460, rather than DEFAULTto emulate the
real application. With IPX, the DEFAULT value is less than 1,460 bytes on all endpoints. To run this
script successfully with IPX, you must change the send_buffer_size variable to a number less than or equal
to the DEFAULT value (which is either 1,391 or 537). See DEFAULT Values for the Endpoints on
page 11 for a table of the byte sizes used for buffers at each endpoint.
For more information, see the Cisco Systems Web site at http://www.cisco.com/iptv.
Endpoint 1
MPV
SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
SEND
file_size=365000
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
START_TIMER
RECEIVE
file_size=365000
END_TIMER
END_LOOP
DISCONNECT
70
Variable Name
Chariot Default
Description
initial_delay
Pause before the

first transaction
100
How many timing

records to
generate
file_size
365,000
How many bytes

in the transferred
file
send_buffer_size
1,460
How many bytes

of data in each
SEND
receive_buffer_size
DEFAULT
How many bytes

of data in each
RECEIVE
send_datatype
NOCOMPRESS
What type of data

to send
send_data_rate
1451.0 kbps
How fast to send

data
port_number
AUTO
What port to use

between endpoints
71
NETMTGA Script (NetMeeting v2.1 audio stream)

This streaming script emulates sending an audio stream using Microsoft NetMeeting. Along with the audio
traffic, a small amount of control traffic is exchanged, using a different port number pair, between the
participating computers. The control traffic is not emulated in this script.
The send_data_rate for this audio portion is set to 12 kbps.
The type value for the RTP_PAYLOAD_TYPE is set to G723 for G.723.
See the Microsoft NetMeeting Web site at http://www.microsoft.com/netmeeting for more information.
Endpoint 1
G723
SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
SEND
file_size=1760
send_buffer_size=44
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
START_TIMER
RECEIVE
file_size=1760
END_TIMER
END_LOOP
DISCONNECT
72
Variable Name
Chariot Default
Description
initial_delay
Pause before the

first transaction
100
How many timing

records to
generate
file_size
1,760
How many bytes

in the transferred
file
send_buffer_size
44
How many bytes

of data in each
SEND
receive_buffer_size
DEFAULT
How many bytes

of data in each
RECEIVE
send_datatype
NOCOMPRESS
What type of data

to send
send_data_rate
12.0 kbps
How fast to send

data
port_number
AUTO
What port to use

between endpoints
73
NETMTGV Script (NetMeeting v2.1 video stream)

This streaming script emulates sending a video stream using Microsoft NetMeeting. Along with the video
traffic, a small amount of control traffic is exchanged, using a different port number pair, between the
participating computers. This control traffic is not emulated in this script.
The send_data_rate for this video portion is set to 64 kbps.
The type value for the RTP_PAYLOAD_TYPE is set to H261 for H.261.
See the Microsoft NetMeeting Web site at http://www.microsoft.com/netmeeting for more information.
Endpoint 1
H261
SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
SEND
file_size=20880
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
START_TIMER
RECEIVE
file_size=20880
END_TIMER
END_LOOP
DISCONNECT
74
Variable Name
Chariot Default
Description
initial_delay
Pause before the

first transaction
50
How many timing

records to
generate
file_size
20,880
How many bytes

in the transferred
file
send_buffer_size
522
How many bytes

of data in each
SEND
receive_buffer_size
DEFAULT
How many bytes

of data in each
RECEIVE
send_datatype
NOCOMPRESS
What type of data

to send
send_data_rate
64.0 kbps
How fast to send

data
port_number
AUTO
What port to use

between endpoints
75
NETSHOWU Script (NetShow UDP, 28.8 kbps)

This streaming script emulates a Microsoft NetShow application that is streaming audio/video content. The
NetShow client connects to the server at a rate of 28.8 kbps.
Although you select 28.8 kbps as the data rate in the real application, weve observed that the actual data rate is
20.813 kbps (that is, the rate which the NetShow server sends to a client). If you want to emulate data
streaming at a faster rate, modify the send_data_rate parameter.
See the Microsoft NetShow Web site at http://www.microsoft.com/ntserver/mediaserv/default.asp for more
information.
Endpoint 1
H261
SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
SEND
file_size=10520
send_data_rate=20.813 kbps
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
START_TIMER
RECEIVE
file_size=10520
END_TIMER
END_LOOP
DISCONNECT
76
Variable Name
Chariot Default
Description
initial_delay
Pause before the

first transaction
50
How many timing

records to
generate
file_size
10,520
How many bytes

in the transferred
file
send_buffer_size
526
How many bytes

of data in each
SEND
receive_buffer_size
DEFAULT
How many bytes

of data in each
RECEIVE
send_datatype
NOCOMPRESS
What type of data

to send
send_data_rate
20.813 kbps
How fast to send

data
port_number
AUTO
What port to use

between endpoints
77
NNTP Script (network news transfer protocol)

This script emulates a Usenet news reader using NNTP. A news reader (such as Netscape) follows a clientserver protocol called NNTP to post and retrieve articles from newsgroups. NNTP stands for Network News
Transfer Protocol. Its described in RFC 977. The well-known port number for NNTP flows in TCP/IP is 119.
For this script, we assume the typical user does the following tasks:
Start the news reader and open a news server

Select a newsgroup every so often (5-10 minutes)
Read a message from the newsgroup every so often (10-60 seconds)
These assumptions are reflected in the structure of the script (except for the delay, which, for the sake of
consistency with other scripts, is zero). Endpoint 1 emulates the news reader and Endpoint 2 emulates the
news server.
Starting the news reader and opening a news server

When a news reader is started, it shows a list of news servers. When a user select a news server, the news
reader establishes a connection to it, the news server sends back information about itself, and the news
reader retrieves the article numbers (first, last, number) of all the newsgroups the user is subscribed to.
This task is emulated by the initial connect and the first inner loop in the script.
Selecting a newsgroup
When a user selects a newsgroup, the news reader queries the news server for the header (article subject,
date, sender, etc) of all of the unread articles.
This task is emulated in the second inner loop where Endpoint 1 sends a small request for a header of an
article and Endpoint 2 sends back the header.
Reading a message
When a user selects an article, the news reader requests the header and body of the article.
This task is emulated by the third inner loop of a small size send from Endpoint 1 and a send of the article
header and body from Endpoint 2.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
RECEIVE
server_info_size=25
server_info_size=25
LOOP
START_TIMER
LOOP
LOOP
number_of_groups=10
SEND
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
SEND
server_info_size=25
server_info_size=25
LOOP
LOOP
LOOP
number_of_groups=10
RECEIVE
78
RECEIVE
reply_size=25
reply_size=25
END_LOOP
LOOP
number_of_groups=10
LOOP
number_of_articles=10
SEND
RECEIVE
header_response_size=500
END_LOOP
LOOP
SEND
RECEIVE
article_response_size=1500
SLEEP
article_delay=0
END_LOOP
SLEEP
group_delay=0
END_LOOP
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
SLEEP
SEND
reply_size=25
reply_size=25
END_LOOP
LOOP
number_of_groups=10
LOOP
RECEIVE
SLEEP
SEND
header_response_size=500
END_LOOP
LOOP
RECEIVE
SLEEP
SEND
article_response_size=1500
END_LOOP
END_LOOP
END_LOOP
END_LOOP
DISCONNECT
Variable Name
Chariot Default
Pegasus Default
79
Description
initial_delay

transaction
50

generate
server_info_size
25
25
How many bytes in the server

info
25
25
reply_size
25
25

reply
header_response_size
500
500
How many bytes in the header
article_response_size
1,500
1,500
How many bytes in the article
reply_send_buffer
DEFAULT
DEFAULT

SEND
DEFAULT
DEFAULT

RECEIVE
transaction_delay

responding
send_datatype
news.cmp
news.cmp
control_datatype
trans.cmp
trans.cmp

send
number_of_groups
10
10
Number of groups
number_of_articles
10
10
Number of articles
group_delay
Pause between groups
article_delay
Pause between articles
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
80
NOTESCHK Script (Lotus Notes, check for unread e-mail)

This script emulates a Lotus Notes client periodically checking for new e-mail messages. Endpoint 1, as the
client, requests the list of unread e-mail headers (sender and subject), and Endpoint 2, as the server, sends
the list of unread e-mail headers to the client.
The default for variable reply_size, the list of e-mail headers, is 1,000, which represents 10 unread messages
with a typical header size of 100 bytes.
The well-known port number for Lotus Notes flows in TCP/IP is 1352.
For more information, see the Lotus Web site at http://www.lotus.com/.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
SEND
RECEIVE
reply_size=1000
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
RECEIVE
SLEEP
SEND
reply_size=1000
END_LOOP
END_LOOP
DISCONNECT
Variable Name
Chariot Default
Pegasus Default
81
Description
initial_delay

transaction
100

generate
file_control_size
100
100

control flows
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE

responding
reply_size
1,000
1,000

reply
transaction_delay
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
82
NOTESRCV Script (Lotus Notes, receive e-mail)

This script emulates the receipt of e-mail by a Lotus Notes client. Each transaction represents the transfer of an
e-mail message from the server to the client. Endpoint 1, as the client, requests an e-mail, and Endpoint 2, as
the server, sends it to the client.
The default for variable file_size, the e-mail message, is 2,000 bytes, which includes 1,000 bytes of Lotus Notes
e-mail control information and 1,000 bytes of readable text. The e-mail size (the file_size variable) should
always be at least 1,000 bytesevery e-mail message has that amount of overhead.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
SEND
RECEIVE
file_size=2000
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
RECEIVE
SLEEP
SEND
file_size=2000
END_LOOP
END_LOOP
DISCONNECT
Variable Name
Chariot Default
Pegasus Default
83
Description
initial_delay

transaction
50

generate
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE

responding
file_control_size
50
50

control flows
file_size
2,000
2,000

transferred file
transaction_delay
send_datatype
news.cmp
news.cmp
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
84
NOTESSND Script (Lotus Notes, send e-mail)

This script emulates the sending of e-mail by a Lotus Notes client. Each transaction represents the transfer of
an e-mail message from the client to the server. A single transaction includes both the lookup of the
recipients name on the Lotus Notes local network database and the actual e-mail message itself.
Endpoint 1, as the client, sends an e-mail message, and Endpoint 2, as the server, sends an acknowledgment to
the client.
The default e-mail message size is 2,000 bytes, which includes 1,000 bytes of Lotus Notes e-mail control
information and 1,000 bytes of readable text. The e-mail size (the file_size variable) should always be at least
1,000 bytesevery e-mail message has that amount of overhead.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
SEND
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
RECEIVE
RECEIVE
SLEEP
SEND
SLEEP
user_delay=0
SEND
file_size=2000
RECEIVE
file_size=2000
RECEIVE
reply_size=100
reply_size=100
SLEEP
SEND
reply_size=100
reply_size=100
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
END_LOOP
END_LOOP
DISCONNECT
Variable Name
Chariot Default
Pegasus Default
85
Description
initial_delay

transaction
50

generate
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
file_control_size
25
25

control flows

responding
user_delay
file_size
2,000
2,000

transferred file
reply_size
100
100

reply
transaction_delay
send_datatype
news.cmp
news.cmp
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
86
PACKETL Script (Packet Blaster, long send)

This is the Packet Blaster (Long Send) transaction, which always uses a long connection.
This long-running transaction continuously sends packets from Endpoint 1 to Endpoint 2. This is not a good
transaction for benchmarking because it does not acknowledge that data has been received. Measurements can
be inaccurate, because the script ends without waiting for the receiving side to catch up. This test uses the
FLUSH script command. While it has no effect on TCP/IP, it causes APPC to send data immediately, rather
than waiting to fill buffers.
You may find this script helpful for generating background traffic. Depending on the network protocol you
choose, this script may also allow you some control over the packet size used at the Data Link Control layer.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
SEND
FLUSH
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
RECEIVE
END_LOOP
END_LOOP
DISCONNECT
Variable Name
Chariot Default
Pegasus Default
87
Description
initial_delay

transaction
50

generate
1,000
100
100
send_buffer_size
DEFAULT
DEFAULT

SEND
transaction_delay
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
88
PACKETLR Script (Packet Blaster, long receive)

This is the Packet Blaster Reverse (Long Receive) transaction, which always uses a long connection.
This script receives individual packets, as quickly as possible, without waiting for any kind of response. This
script is similar to PACKETL.SCR, but Endpoint 1 issues receives instead of sends. Measurements are more
accurate, since Endpoint 1 knows exactly how many bytes have been received successfully in each timing
record.
You may find this script helpful for generating background traffic. Depending on the network protocol you
choose, this script may also allow you some control over the packet size used at the Data Link Control layer.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
RECEIVE
END_LOOP
END_TIMER
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
SEND
FLUSH
END_LOOP
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Variable Name
Chariot Default
Pegasus Default
89
Description
initial_delay

transaction
50

generate
1,000
100
100
send_buffer_size
DEFAULT
DEFAULT

SEND
transaction_delay
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
90
PNTCAST1 Script (PointCast v1 Initial/Subsequent Update)

This script represents one user getting an update of the default selections of content for PointCast Network
version 1. There are 75 transactions per record, because it takes about that many connections to download all
of the content.
Every connection is serialized, so only one endpoint connection is needed. Each connection is composed of a
request (from the client to the server) and a response (which contains the requested content). The average
request and response sizes are 150 and 15,000 bytes, respectively.
For more information on the PointCast Network, see the PointCast Web site at http://www.pointcast.com.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
LOOP
75
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
file_size=15000
DISCONNECT
END_LOOP
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
LOOP
75
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
SEND
file_size=15000
DISCONNECT
END_LOOP
END_LOOP
END_LOOP
Variable Name
Chariot Default
Pegasus Default
91
Description
initial_delay

transaction
50

generate
150
150
file_size
15,000
15,000

transferred file
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE

responding
transaction_delay
send_datatype
NOCOMPRESS
NOCOMPRESS
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
92
PNTCAST2 Script (PointCast v2 Initial/Subsequent Update)

This script represents one user getting an update of the default selections of content for PointCast Network
version 2 (beta). Some of the connections occur in parallel, while others are serialized. Up to 5 connections
occur in parallel, so 5 identical endpoint connections are needed, with 25 transactions per record, to download
all the contents.
Every connection is serialized, so only one endpoint connection is needed. Each connection is composed of a
request (from the client to the server) and a response (which contains the requested content). The average
request and response sizes are 250 and 10,000 bytes, respectively.
For more information on the PointCast Network, see the PointCast Web site at http://www.pointcast.com.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
LOOP
25
CONNECT_INITIATE
port_number=AUTO
SEND
RECEIVE
file_size=10000
DISCONNECT
END_LOOP
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
Endpoint 2
----------
LOOP
LOOP
LOOP
25
CONNECT_ACCEPT
port_number=AUTO
RECEIVE
SLEEP
SEND
file_size=10000
DISCONNECT
END_LOOP
END_LOOP
END_LOOP
Variable Name
Chariot Default
Pegasus Default
93
Description
initial_delay

transaction
50

generate
250
250
file_size
10,000
10,000

transferred file
send_buffer_size
DEFAULT
DEFAULT

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE

responding
transaction_delay
send_datatype
NOCOMPRESS
NOCOMPRESS
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
94
POP3 Script (receive e-mail)

This application script emulates the receiving of e-mail messages. It emulates receiving an e-mail file at
Endpoint 1 from Endpoint 2, using TCP/IPs POP3 standard.
The default file size (that is, the size of an e-mail message) is 1,000 bytes, with a 20-byte header; the default
data type for the e-mail message is NEWS.CMP.
There are three sections in this script, each with its own purpose. The first section emulates a logon by
Endpoint 1 to Endpoint 2. The second section, within the loop of transactions_per_record emulates the
receiving of a mail message. To emulate a user who receives a large number of mail messages in a single
logon, increase the transactions_per_record variable. The third section emulates a user logging off.
1.
then receives a request for a password, and replies by sending a password. It then receives the
acknowledgment that the logon is successful. Finally, it sends a request for the number of available e-mail
messages and receives the response.
2.
In the inner loop of the second section, Endpoint 1 sends a request for a specific e-mail message. It then
receives the message header followed by the body of the message. Finally, it sends a request to delete this
e-mail message and receives an acknowledgment.
3.
The script variable named number_of_timing_records lets you repeat the entire POP3 script, including the
logon and logoff processing.
The well-known port number for POP3 flows in TCP and UDP is 110.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
CONNECT_INITIATE
port_number=AUTO
RECEIVE
SEND
reply_size=20
reply_size=20
RECEIVE
reply_size=20
SEND
reply_size=20
reply_size=20
Endpoint 2
----------
LOOP
CONNECT_ACCEPT
port_number=AUTO
SEND
RECEIVE
reply_size=20
server_buffer_size=8192
SEND
reply_size=20
reply_size=20
RECEIVE
reply_size=20
RECEIVE
SEND
RECEIVE
reply_size=20
LOOP
SEND
RECEIVE
reply_size=20
RECEIVE
file_size=1000
SEND
RECEIVE
reply_size=20
END_LOOP
SEND
RECEIVE
DISCONNECT
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
SEND
RECEIVE
SEND
reply_size=20
reply_size=20
LOOP
RECEIVE
SEND
reply_size=20
reply_size=20
SEND
file_size=1000
file_size=1000
RECEIVE
SEND
reply_size=20
reply_size=20
END_LOOP
RECEIVE
SEND
DISCONNECT
END_LOOP
95
96
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
receive_buffer_size
1,024
1,024

RECEIVE
server_buffer_size
8,192
8,192
How many bytes in server

RECEIVEs
reply_size
20
20

reply
file_size
1,000
1,000

transferred file
file_control_size
70
70

control flows
transaction_delay
send_datatype
news.cmp
news.cmp
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
97
REALAUD Script (RealAudio, CD streaming)

This streaming script emulates the RealAudio application that is multicasting audio content from a multimedia
CD-ROM.
The send_data_rate variable defaults to an average rate of 80 kbps.
The type value for the RTP_PAYLOAD_TYPE is set to G729 for G.729.
For more information, see the RealNetworks Web site at http://www.real.com/
The discussion of Streaming Scripts provides details on endpoint operation and the performance statistics
that are collected when running this script.
Endpoint 1
G729
SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
SEND
file_size=14040
send_data_rate=80.736 kbps
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
START_TIMER
RECEIVE
file_size=14040
END_TIMER
END_LOOP
DISCONNECT
98
Variable Name
Chariot Default
Description
initial_delay
Pause before the

first transaction
100
How many timing

records to
generate
file_size
14,040
How many bytes

in the transferred
file
send_buffer_size
351
How many bytes

of data in each
SEND
receive_buffer_size
DEFAULT
How many bytes

of data in each
RECEIVE
send_datatype
NOCOMPRESS
What type of data

to send
send_data_rate
80.736 kbps
How fast to send

data
port_number
AUTO
What port to use

between endpoints
99
REALMED Script (RealMedia, Stream Smart audio-video)

This streaming script emulates a RealNetworks server streaming a combined audio and video file over a fast
Ethernet link. The file was encoded with Stream Smart technology, using the G2 version of the encoder, and
played with the G2 version of the server. The player used is version 5 of the RealNetworks player.
The send_data_rate variable defaults to an average rate of 300 kbps.
For more information, see the RealNetworks Web site at http://www.real.com/
Endpoint 1
H261
SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
SEND
file_size=17240
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
START_TIMER
RECEIVE
file_size=17240
END_TIMER
END_LOOP
DISCONNECT
100
Variable Name
Chariot Default
Description
initial_delay
Pause before the

first transaction
100
How many timing

records to
generate
file_size
17,240
How many bytes

in the transferred
file
send_buffer_size
431
How many bytes

of data in each
SEND
receive_buffer_size
DEFAULT
How many bytes

of data in each
RECEIVE
send_datatype
NOCOMPRESS
What type of data

to send
send_data_rate
300.0 kbps
How fast to send

data
port_number
AUTO
What port to use

between endpoints
SAPAUTHP Script (SAP R/3, authorize payment on invoice)

This script emulates the authorization of payment on the invoice prepared using SAPINV.SCR. Each
transaction represents one authorization of payment and release of an invoice.
For more information, see the SAP Web site at www.sap.com.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
LOOP
25
SEND
send_datatype=trans.cmp
RECEIVE
reply_size=600
END_LOOP
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
LOOP
25
RECEIVE
SLEEP
SEND
reply_size=600
END_LOOP
END_LOOP
END_LOOP
DISCONNECT
101
102
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
10
100
100
inquiry_send_buffer
DEFAULT
DEFAULT

SEND
DEFAULT
DEFAULT

RECEIVE

responding
reply_size
600
600
reply_send_buffer
DEFAULT
DEFAULT

SEND
DEFAULT
DEFAULT

RECEIVE
transaction_delay
send_datatype
trans.cmp
trans.cmp
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
103
SAPINV Script (SAP R/3, prepare an invoice)

This script emulates the preparation of an invoice based on the purchase order created using SAPPUROR.SCR.
Each transaction represents the transfer of one invoice for payment in the SAP system. Endpoint 1, as the
client, requests invoice and payment information. Endpoint 2, as the server, responds with a customer invoice.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
LOOP
11
SEND
RECEIVE
reply_size=1100
END_LOOP
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
LOOP
11
RECEIVE
SLEEP
SEND
reply_size=1100
END_LOOP
END_LOOP
END_LOOP
DISCONNECT
104
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
10
100
100
inquiry_send_buffer
DEFAULT
DEFAULT

SEND
DEFAULT
DEFAULT

RECEIVE

responding
reply_size
1,100
1,100
reply_send_buffer
DEFAULT
DEFAULT

SEND
DEFAULT
DEFAULT

RECEIVE
transaction_delay
send_datatype
trans.cmp
trans.cmp
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
SAPLOGIN Script (SAP R/3, login)

This script emulates a login to an SAP server.
Endpoint 1, as the SAP R/3 client, sends login and control messages to Endpoint 2, acting as the server.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
LOOP
5
SEND
RECEIVE
reply_size=500
END_LOOP
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
LOOP
5
RECEIVE
SLEEP
SEND
reply_size=500
END_LOOP
END_LOOP
END_LOOP
DISCONNECT
105
106
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
50
100
100
inquiry_send_buffer
DEFAULT
DEFAULT

SEND
DEFAULT
DEFAULT

RECEIVE

responding
reply_size
500
500
reply_send_buffer
DEFAULT
DEFAULT

SEND
DEFAULT
DEFAULT

RECEIVE
transaction_delay
send_datatype
trans.cmp
trans.cmp
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
107
SAPPUROR Script (SAP R/3, purchase order)

This script emulates the creation of a purchase order by an SAP operator at the client. Each transaction
represents the transfer of one purchase order in the SAP system. Endpoint 1, as the client, sends a purchase
order request and Endpoint 2, as the server, responds with order information.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
LOOP
28
SEND
RECEIVE
reply_size=1400
END_LOOP
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
LOOP
28
RECEIVE
SLEEP
SEND
reply_size=1400
END_LOOP
END_LOOP
END_LOOP
DISCONNECT
108
Variable Name
Chariot Default
Pegasus Default
Description
initial_delay

transaction
50

generate
10
50
50
inquiry_send_buffer
DEFAULT
DEFAULT

SEND
DEFAULT
DEFAULT

RECEIVE

responding
reply_size
1,400
1,400
reply_send_buffer
DEFAULT
DEFAULT

SEND
DEFAULT
DEFAULT

RECEIVE
transaction_delay
send_datatype
trans.cmp
trans.cmp
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
109
SMTP Script (simple mail transfer protocol)

This script emulates the sending of e-mail messages. It emulates sending an e- mail message from Endpoint 1
to Endpoint 2, using TCP/IPs SMTP standard.
The default file size (that is, the size of an e-mail message) is 1,000 bytes, with a 20-byte header. Note that if
the response time is faster if you use a file size that is larger than the underlying MTU size. For example, use
1,461 bytes or larger on Ethernet. The default data type for the e-mail message is NEWS.CMP.
Each connection goes through three sections, each with its own purpose.
1.
In the first section, Endpoint 1 establishes a connection with the SMTP server and sends the identity of the
mail sender and receiver.
2.
In the second section, Endpoint 1 sends the body of the e-mail message. See the SEND command, which
uses the size_of_record_to_send variable.
3.
In the third section, Endpoint 1 sends a message indicating that the message is complete, and receives an
The script variable named transactions_per_record lets you emulate the sending of multiple e-mail messages
per timing record, including the logon and logoff processing. The script variable named
number_of_timing_records lets you repeat the entire SMTP script.
The well-known port number for SMTP flows in TCP/IP is 25.
Endpoint 1
---------SLEEP
initial_delay=0
LOOP
START_TIMER
LOOP
CONNECT_INITIATE
port_number=AUTO
RECEIVE
reply_size=10
SEND
reply_size=10
reply_size=10
RECEIVE
SEND
RECEIVE
reply_size=10
Endpoint 2
----------
LOOP
LOOP
CONNECT_ACCEPT
port_number=AUTO
SEND
reply_size=10
reply_size=10
RECEIVE
reply_size=10
SEND
RECEIVE
SEND
reply_size=10
reply_size=10
110
SEND
RECEIVE
SEND
reply_size=10
reply_size=10
RECEIVE
SEND
file_size=1000
file_size=1000
SEND
reply_size=10
reply_size=10
RECEIVE
DISCONNECT
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
RECEIVE
SEND
RECEIVE
reply_size=10
SEND
RECEIVE
file_size=1000
RECEIVE
reply_size=10
SEND
DISCONNECT
END_LOOP
END_LOOP
Variable Name
Chariot Default
Pegasus Default
111
Description
initial_delay

transaction
50

generate
40
40
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
reply_size
10
10

reply
DEFAULT
DEFAULT

RECEIVE
file_size
1,000
1,000

transferred file
transaction_delay
send_datatype
news.cmp
news.cmp
control_datatype
trans.cmp
trans.cmp

send
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
112
TELNET Script (remote terminal session)

This script emulates a TCP/IP Telnet session. The default values show that Endpoint 1 sends one byte of data
to Endpoint 2, which replies by echoing the same one-byte record. Endpoint 1 contains a SLEEP inside its
inner loop: user_delay. Set this sleep period to a non-zero value to emulate the time that users pause between
keystrokes when typing. The default data type for the exchanged bytes is TRANS.CMP.
The receive buffer size is set to DEFAULT, for compatibility with all operating systems and protocols. A
receive buffer size of 4,096 bytes is commonly used by Telnet applications.
The INQUIRYL Script (Inquiry, long connection) is structured similarly, but with different script variable
defaults.
The well-known port number for Telnet flows in TCP/IP is 23.
The INQUIRYL Script (Inquiry, long connection) is structured similarly, but with different script variable
defaults.
Endpoint 1
---------SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
START_TIMER
LOOP
SEND
RECEIVE
SLEEP
user_delay=0
END_LOOP
END_TIMER
SLEEP
transaction_delay=0
END_LOOP
DISCONNECT
Endpoint 2
----------
CONNECT_ACCEPT
port_number=AUTO
LOOP
LOOP
RECEIVE
SLEEP
SEND
END_LOOP
END_LOOP
DISCONNECT
Variable Name
Chariot Default
Pegasus Default
113
Description
initial_delay

transaction
50

generate
50
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE

responding
user_delay
transaction_delay
send_datatype
trans.cmp
trans.cmp
send_data_rate
UNLIMITED
UNLIMITED
port_number
AUTO
AUTO

endpoints
114
VOIPS Script (voice over IP send)

This streaming script is modeled after a voice over IP (VOIP) session conducted by an equipment vendor in the
course of qualifying their equipment. The script generates a stream of packets where the data payload is 40
bytes each. VOIP transmissions currently run at rates between 4 kbps and 68 kbps in each direction. The
default send_data_rate here is 64 kbps.
This script simulates a G.711 stream at 64kbps. The type value for the RTP_PAYLOAD_TYPE is set to
PCMU. PCMU is the U.S. version of G.711 and PCMA is the European version of G.711.
Endpoint 1
----------
Endpoint 2
----------
SLEEP
initial_delay=0
CONNECT_INITIATE
port_number=AUTO
LOOP
SEND
file_size=4560
send_buffer_size=40
END_TIMER
END_LOOP
DISCONNECT
END_LOOP
DISCONNECT
Variable Name
CONNECT_ACCEPT
port_number=AUTO
LOOP
START_TIMER
RECEIVE
file_size=4560
Chariot Default
Pegasus Default
Description
initial_delay

transaction
100

generate
file_size
4,560
4,560

transferred file
send_buffer_size
40
40

SEND
receive_buffer_size
DEFAULT
DEFAULT

RECEIVE
send_datatype
NOCOMPRESS
NOCOMPRESS
send_data_rate
64.0 kbps
64.0 kbps
port_number
AUTO
AUTO

endpoints
Messages
115
Messages
In the following message descriptions, %N (where N is a number like 1 or 2) in the message text indicates a
replacement variable. When the message is shown by a Ganymede Software program, data pertaining to the
error is shown in its place.
CHR0000
CHR0000: Internal error: invalid message number.
Explanation
A Ganymede Software program issued a request to load a message using an invalid message number.
This is a program defect.
Operator Action
Please contact Ganymede Software service. See Technical Support for information on contacting
Ganymede Software.
CHR0005
CHR0005: The build level of the message file (%1) is incompatible with the program build level (%2).
Explanation
The message file that was loaded is for the product build level specified in the %1 variable. The
program youre running is for the product build level specified in the %2 environment variable. The
message file build level must match the program build level.
Endpoint installation adds its directory to the DPATH in your CONFIG.SYS file. If youve installed a
different version of the endpoint in a different directory, the current endpoint may be attempting to
load the wrong message file. In addition, the endpoint program or one of the Chariot console
programs may be running already; it may have loaded the wrong version of the required DLLs.
Operator Action
Ensure that there is only one copy of the message file (ECHR.MSG) on your computers DPATH.
Ensure that other Chariot programs are not running already.
CHR0101
CHR0101: Out of memory.
116
Explanation
A Ganymede Software program issued a call requesting memory and no memory was available.
Likely Causes
This program and/or other programs on the computer are using all available memory. On an operating
system that swaps memory to disk (such as OS/2 or Windows NT), the disk containing the swap file
may be full.
Operator Action
First check which computer detected the error. See Determining Which Computer Detected an Error
for information about how to determine this.
If the error was detected by the Chariot console, you can:
Free up space on the swapper disk. For help determining the location of your swap disk
on OS/2, use "HELP SWAPPATH"; on Windows NT, find the System dialog in the
Control Panel, and examine the Virtual Memory settings.
Close other running programs to free up memory for Chariot to use.
Reduce Chariots memory requirements by closing Test windows that you arent using or
by reducing the number of endpoint pairs in each test.
Add more memory to your computer.
If the error was detected by the Pegasus server, you can:
Free up space on the swap disk. For help determining the location of your swap disk on
Windows NT, find the System dialog in the Control Panel, and examine the Virtual Memory
settings.
Close other running programs to free up memory for Pegasus to use.
If the error was detected by an endpoint, you can:
Free up space on the swapper disk. Refer to the operating system documentation to find
which drive is your swapper disk.
Close other running programs to free up memory for the endpoint to use.
Reduce the endpoints memory requirements by changing the test to run fewer connections on
that particular endpoint.
CHR0102
CHR0102: Out of disk space.
Explanation
While writing a file, an error was encountered indicating that the disk is full.
Messages
117
Operator Action
To avoid this error, you can:
Make space on the target disk by erasing or compressing other files on that drive. You
can use operating system commands or utilities to do this.
Save the file to another disk which has more space available.
CHR0103
CHR0103: Out of threads.
Explanation
A Ganymede Software program attempted to start a thread to fulfill a request, but the operating system
could not start a new thread.
Likely Causes
The operating system already has its maximum number of threads running.
Operator Action
We have observed that when this condition occurs, communications calls can hang which, in turn,
causes application programs making those calls to appear to hang. Depending upon where the out-ofthreads condition occurred, you may need to exit your program and/or manually restart endpoints, in
addition to performing the actions outlined below.
If the computer is running OS/2, you can:
Increase the maximum number of OS/2 threads. For help determining how to change the
maximum number of threads, enter "HELP THREADS" at an OS/2 command-line
prompt. Update CONFIG.SYS and reboot to make the change take effect.
Close other running programs, to free up threads.
If the computer is running Windows 95, 98, or NT, you can:
Increase the maximum number of threads that Windows 95/98 or NT allow.
Close other running programs, to free up threads.
If the endpoint computer is running AIX, HP-UX, or Sun Solaris, it says that the endpoint has
encountered the following condition: "error forking child: Not enough space." See the endpoint
documentation for details on correcting this condition.
If the error occurred on the Chariot console, you may need to exit the console to free up threads that
were started before the error occurred.
118
If the error occurred on the Pegasus server, you may need to stop and restart the Pegasus server to free
up threads that were started before the error occurred.
CHR0104
CHR0104: Unexpected C runtime error. Errno is %1. Runtime message is: "%2"
Explanation
A Ganymede Software program issued a C runtime call that failed with an unexpected error.
This is the information returned by the C runtime routine. The %1 variable above is filled in with Cs
errno value for the failure. The C runtime message associated with that errno is provided in the %2
variable.
When the errno is 60 and the %2 variable is blank, the operating system is probably out of memory.
Operator Action
Try to interpret the runtime message in the %2 variable and use it to fix the problem.
In addition, please contact Ganymede Software service so we can provide a better error message in
future versions of our products. See Technical Support for information contacting Ganymede
Software.
CHR0108
CHR0108: The registration number does not allow you to use this product.
Explanation
The registration number you entered is not valid.
Operator Action
Ensure that the registration number you entered matches the registration number provided with the
program materials. If it does match and this problem persists, please contact Ganymede Software
Customer Care. See Technical Support for information on contacting Ganymede Software.
CHR0109
CHR0109: Attempted to exceed the maximum number of pairs allowed %1.
Explanation
Your product license limits the number of endpoint pairs that you can configure or use in a single test
file. The number of allowable pairs is shown in the message and can also be found in the About box or
in the first few lines of output of the command-line programs.
Operator Action
Messages
119
Use tests which do not contain more pairs than your license permits.
CHR0110
CHR0110: The file did not contain the correct Chariot file type identifier.
Explanation
Chariot files have a type and version identifier built into them to prevent loading the wrong type of
file. For example, this prevents you from opening a script file as a test file.
This message also occurs when trying to open a file from a more recent software version. For example,
an older Chariot console at version 1.1 cannot open a newer test file created at version 2.x.
Operator Action
Ensure that youre opening the right type of file for what youre trying to do. In other words, select a
file which is of the correct type and version expected by the Chariot program.
CHR0111
CHR0111: The file did not contain the necessary copyright string.
Explanation
Stored within each Chariot input file is a Ganymede copyright string. Although the file you were
loading appeared to be a valid file, it did not have the required copyright string.
Operator Action
Select a file that was either supplied by Ganymede Software or created by the Chariot software.
CHR0112
CHR0112: The file did not contain the expected verification identifier.
Explanation
Chariot input files have a verification identifier built into them to prevent you from accidentally
loading the wrong type of file. For example, this prevents you from loading a word processing file as a
script to use within a test.
Operator Action
Select a file that was either supplied by Ganymede Software or created by the Chariot software.
CHR0113
CHR0113: The cyclical redundancy check (CRC) for the file did not match the expected value. Check
message help for causes of this error.
120
Explanation
Chariot input files have a CRC built into them to prevent you from loading the wrong type of file into
a program, or from loading a corrupted file.
Likely Causes
Possibilities include:
The file doesnt contain what you expect. For example, you cannot open a spreadsheet
file as a Chariot test file, or run FMTTST against a log file.
The file contents have been modified using an editor.
Youve requested validation of received data, and the .CMP file at the receiving endpoint
has been corrupted or edited.
A disk error has corrupted part or all of the file.
Operator Action
Check the name and directory of the file, to ensure its what you expected.
Use a backup copy of the file. There is no way to recover a file that has been corrupted or edited. You
can restore a corrupted .CMP file by reinstalling the endpoint.
CHR0114
CHR0114: An unexpected EOF occurred during a file read.
Explanation
While reading a file, the program encountered an end-of-file indicator when more data was expected.
Likely Causes
The file was corrupted or edited by a program other than the one youre using.
The file was changed (written to) by another program while this program was reading it.
Operator Action
Use a backup copy of the file. There is no way to recover a file that has been corrupted or edited.
CHR0115
CHR0115: An attempt made to open a file that is already open.
Explanation
Messages
121
Another program has already opened this file; the file is locked such that other programs cannot open
it.
Likely Causes
The file is being used by the Chariot console, or one of the command-line programs (such as
RUNTST, FMTTST, CLONETST, or FMTLOG). Another user may have the file open, if this file is
on a shared drive such as a LAN file server.
This message can also indicate that the drive is full, and a previous write to this file failed. This may
mean that the file could not be closed. You cannot erase this file (or open it again) until the Chariot
program ends.
Operator Action
Consider one of these actions:
See if the file is in use by another user.
Close the file in the other program.
Wait until the other program has finished using the file.
Use a different file name.
CHR0116
CHR0116: An attempt made to create a file that already exists.
Explanation
This error should not occur in this version of Chariot.
Operator Action
Ganymede Software.
CHR0117
CHR0117: An attempt made to read or write a file that could not be found.
Operator Action
Specify the name of a file in a directory that exists on an accessed drive. Ensure that the drive is ready
(for example, a diskette is in the diskette drive, a CD is in the CD-ROM drive, or the network drive is
accessible). Also, be sure that the filespec is valid for the drive you are using.
If youre using Chariot, open the Change User Settings notebook, under the Options menu in the Main
Window. On the Directories tab, ensure that the drives and paths are valid and that theyre what you
intend.
122
CHR0118
CHR0118: An attempt made to open a file for writing, where the file or drive is "read-only."
Operator Action
The file may be marked read-only.

On OS/2 and the Windows family you can change this by using the ATTRIB command.
For example:
attrib -r FILENAME.TST
The file may be on a read-only drive, such as a CD-ROM drive.

Change the filename to specify a drive which is read/write.
The file may be on a LAN network drive to which you do not have write permission.
Have your LAN administrator give you write permission, or change the filename to
specify another location.
The drive is full, and a previous write to this file failed. This may mean that the file
could not be closed. You cannot erase this file (or write to it again) until the Chariot
program ends.
CHR0119
CHR0119: An attempt made to open a file, where the filespec (drive, path, filename, and extension) is too
long.
Operator Action
Specify a shorter filename, or one that meets the naming conventions of the operating system or file
system in use.
CHR0120
CHR0120: An attempt made to write a file to a network drive, to which access is denied.
Explanation
You do not have write-permission on the network drive.
Operator Action
Either specify a drive/directory to which you have write access, or change the access permission of the
network drive.
Messages
123
CHR0121
CHR0121: An OS/2 write fault error occurred while attempting to write a file to disk. The file could not
be closed.
Explanation
Unable to write to this disk. The disk may be full. (It is likely that the target disk is a VDISK.)
In addition, the file could not be closed. This means that you cannot erase the file until the Chariot
program ends.
Operator Action
Either specify a different drive, clear some files from the existing disk, or get a larger disk.
Make space on the disk in use by erasing or compressing other files on that drive. You
can use operating system commands or utilities to do this.
Save the file to another disk which has more space available.
CHR0122
CHR0122: The received data did not contain the necessary identifier.
Explanation
When the endpoints are contacted, or connect to each other, they exchange a special ID. This ID is
used to verify that they are connected correctly. One of the participants of this initialization exchange
did not specify the correct verification ID.
Likely Causes
Chariot or Pegasus is not connecting to a valid endpoint.
Chariot or Pegasus is connecting to a defective endpoint.
Operator Action
Ensure that the Chariot or Pegasus program is connected to a valid endpoint. If you can verify that
this is the case, please contact Ganymede Software service. See Technical Support for information on
contacting Ganymede Software.
CHR0123
CHR0123: The received data did not contain the necessary copyright string.
Explanation
The partner program did not include the required copyright string in the message exchange.
124
Likely Causes
Chariot or Pegasus is not connecting to a valid program.
Chariot or Pegasus is connecting to a defective program.
Operator Action
Ensure that the Chariot or Pegasus program is connected to another Chariot or Pegasus program. If
you can verify that this is the case, please contact Ganymede Software service. See Technical Support
for information on contacting Ganymede Software.
CHR0124
CHR0124: Partner program sent data that could not be successfully parsed.
Explanation
An unrecognized data flow was received.
Likely Causes
Operator Action
CHR0125
CHR0125: %1 does not support the following function(s) required to run this test: %2
Explanation
In preparation for running a test, Chariot or Pegasus contacts each of the endpoints to ensure that they
are capable of running the test. One of the endpoints does not support a feature required to run this
test.
The Chariot console or Pegasus server was able to connect successfully to the endpoint program in
question. That endpoint program, however, stopped the run because it did not have the level of
function needed for this test.
Likely Causes
Messages
125
This error may be returned when connected to old or future endpoints which do not support endpoint
functions needed for the test. If the endpoint is old, this problem may be corrected by upgrading to the
latest level.
A common cause for this error is trying to use a streaming script or specifying a send_data_rate with
an earlier version of an endpoint.
You may also receive this error if you use Windows 3.1 as Endpoint 1 in a multicast group. Windows
3.1 is not supported as Endpoint 1 in a multicast group.
Another cause for this error is if the endpoint supports the functionality in the test, but the operating
system does not support the functionality. For example, if you have the correct Endpoint level, but you
are trying to run QoS on any system on any system other than Windows 98 or Windows 2000.
Operator Action
Consult the endpoint documentation for the specific operating system on which the endpoint in
question is running.
CHR0126
CHR0126: A report was received that was not intended for this program or is for an old run.
Explanation
An endpoint that was started during a previous run is still active and returned a report. This does not
affect the run currently in progress.
Operator Action
None necessary.
CHR0127
CHR0127: The APPC connection could not be established.
Explanation
An APPC session could not be obtained for a conversation; the problem may be temporary, but human
intervention will probably be needed to correct the problem.
The underlying failure code could have indicated either RETRY or NO_RETRY. If the failure code
indicated RETRY, the connection attempt has already been retried every 200 milliseconds for at least
10 seconds before giving up and generating this error message.
Likely Causes
There are thousands of reasons for this return code. A specific reason for the failure can be found in
the SNA sense data associated with this return code. This sense code can be found in the CHR0128
message.
Operator Action
126
Examine the documentation for the associated sense code; this should provide information about how
to fix the problem.
You can also examine any platform-related message logs and error logs at both locations to find more
information about this problem. Look for equipment failures or setup problems related to the network
components and the computers using them.
CHR0128
CHR0128: Sense data is %1
Explanation
This message provides additional information about a connection establishment error. (See message
CHR0127.)
SNA Server for Windows NT often returns sense data that is nonsensical. IBM Communications
Server for Windows NT and IBM Personal Communications will both return 00000000 sense data on
many occasions where better sense data could have been given.
Operator Action
Look up this sense code in the Chariot online help. If the sense code does not appear in the help and
you are using SNA Server for Windows NT, it is possible that the sense code is meaningless.
Unfortunately there is no known way of obtaining a valid sense code to further clarify the problem. If
the sense data is 00000000 and you are using either IBM Communications Server for Windows NT or
IBM Personal Communications then it may be because all the available sessions are being used. Look
at the sense data information for FFFE0016 or 08050000 to see if either of these apply. If neither of
these apply, then there is unfortunately no further information given to help isolate the cause of the
problem.
CHR0129
CHR0129: An established APPC connection failed during processing.
Explanation
The active conversation has been unexpectedly ended. Although it is possible that restarting the
connection could be successful, this failure disrupts the validity of test results, and thus is always
flagged as an error.
Likely Causes
Some aspect of the partner computer, needed for APPC communication, has been deactivated. Here
are some examples of how this return code is caused.
The partner computer was powered off or rebooted during the conversation.
The partner computer stopped or unloaded its APPC software during the conversation.
The partner computer deactivated its data link control (DLC) during the conversation.
Messages
127
The local or partner LU deactivated the session in the middle of a conversation. This
may have been done using the protocol stacks management or administration program.
The local LU was notified of a session outage occurring in the network.
The local and partner LUs have been disconnected from each other. The link or session
has been abruptly terminated.
The partner program was deactivated while it was running. If the partner is using OS/2
Communications Manager, this can be done using Communications Manager Subsystem
Management. This may have been done using the protocol stacks management or
administration program.
The partner computer may have violated internal SNA protocols.
Operator Action
Examine any platform-related message logs and error logs at both locations to find more information
about this problem. Look for equipment failures or setup problems related to the network components
and the computers using them. Fix the problem, as indicated by any SNA sense data associated with
this call. (Unfortunately, SNA sense data is not available when the failure occurs after the
conversation has been successfully established.) You may need to run the applications again with SNA
tracing activated to get the sense data.
After correcting the problem, try running the test again.
CHR0130
CHR0130: The partner program issued an unexpected APPC call.
Explanation
The partner program issued a call or sequence of calls that violated the internal rules for using APPC
conversations.
Likely Causes
Operator Action
CHR0131
CHR0131: The APPC communications subsystem is not loaded.
128
Operator Action
If the Chariot console or Pegasus server is the computer detecting this error, it may be due to the use
of LU aliases instead of fully-qualified LU names in the test. If an APPC stack is installed on that
computer, the software attempts to resolve all LU aliases to fully-qualified names.
If the computer is running OS/2, you can do one of the following to start OS/2 Communications
Manager:
Find the "Start Communications" icon in the Communications Manager folder and
double-click on the icon.
From a command prompt, run "CMSTART".
If the computer is running Windows NT, you can do the following to start
Microsoft SNA Server:
From the Windows NT Control Panel, select Services. From Services, select the
SnaBase service and choose Start.
From the SNA Server Administration program, ensure that the SNA Server for
Windows NT "Server" component is active.
IBM Communications Server or IBM Personal Communications
From the SNA Node Operations window choose Operations...Start Node, select
the appropriate configuration and click OK to start.
CHR0132
CHR0132: An unexpected APPC communications return code received.
Explanation
An unrecognized APPC return code was returned on an APPC call.
Operator Action
To solve the underlying problem, you must first find the APPC return code, which should be in a
second message returned along with this message. You need to look for this APPC return code in the
appropriate platform documentation.
To help Ganymede Software provide better diagnostics in the future, please contact Ganymede
Software service and tell us about what return code you received and how it was generated. See
Technical Support for information on contacting Ganymede Software.
CHR0133
CHR0133: The name specified is not recognized as a valid partner LU alias or mode name.
Messages
129
Explanation
This error can be caused by either of two conditions:
You specified a network address that was interpreted as an OS/2 APPC partner LU alias.
This partner LU alias was not configured on the computer which detected the error.
You specified an invalid mode name. The mode name that this endpoint pair attempted
to use is either not configured or is not valid for the partner LU specified.
Likely Causes
Either:
You specified a non-fully-qualified network address that was not known at the Chariot
console and which was also not known on the computer which detected the error. LU
aliases are "case-sensitive." You may have entered the wrong combination of uppercase
and lowercase letters.
You specified an incorrect mode name in the Service Quality field of the endpoint pair in
error.
Operator Action
To see the partner LU aliases on the computer which detected the error (and where CM/2 is running),
enter "DISPLAY -PL" at an OS/2 prompt.
Correct the network address by doing one of the following:
Specify the partner LU alias with the correct combination of uppercase and lowercase
letters
Specify a fully-qualified APPC network name
Specify a partner LU alias that is defined on the Chariot console computer
Specify a partner LU alias that is defined on the computer which in this case detected an
error.
Or, select a mode name from those currently configured at both LUs in the test.
CHR0134
CHR0134: An internal coding bug has been detected.
Operator Action
Ganymede Software.
CHR0135
CHR0135: There is no remote program waiting to accept our APPC connection.
130
Explanation
The partner computer rejected the incoming APPC Attach because the endpoint program was not
running on that computer, or the endpoint program has encountered an error.
Likely Causes
The endpoint program is not running.
In OS/2, the APPC attach manager associated with the partner LU is stopped. This can
be caused by a missing START_ATTACH_MANAGER statement in the
Communications Manager (.NDF) node definitions file.
The endpoint may have been restricted from using APPC in the ENDPOINT.INI file.
Operator Action
On the partner computer, check that the endpoint is still running. If it is, check if there are any error
log entries in the ENDPOINT.LOG file.
CHR0136
CHR0136: The buffer size specified (%1) is larger than the APPC maximum buffer size (%2).
Explanation
The script that was run specified a buffer size for SEND or RECEIVE that was larger than that
allowed for APPC.
Operator Action
Edit the endpoint pair on which this error occurred and modify any buffer sizes that exceed the
protocol maximum.
CHR0137
CHR0137: An APPC conversation security failure occurred.
Explanation
The partner computer rejected the security information received on an incoming Attach.
You may see this return code associated with SNA sense data 080F6051.
Likely Causes
Ganymede Software programs always uses SECURITY=NONE, so this is likely a configuration
problem on the partner computer.
Operator Action
Messages
131
Check that the partner computer is configured not to require conversation security for the ENDPOINT
TP definition.
CHR0138
CHR0138: A disconnect issued when the APPC conversation is not in the correct state.
Explanation
This is a secondary message providing more information about why a CHR0130 message occurred.
CHR0139
CHR0139: The name of the partner APPC program is not recognized at the partner computer.
Explanation
CHR0140
CHR0140: The partner APPC program could not be started.
Explanation
CHR0141
CHR0141: An unexpected data received value encountered on an APPC Receive() call.
Explanation
The partner program issued a call or sequence of calls that violated the internal rules for using APPC
conversations.
Likely Causes
Operator Action
132
CHR0142
CHR0142: The hostname specified could not be found by the name server.
Explanation
You specified a fully-qualified hostname containing a domain name. Although the name server
owning the domain was located, it did not have the address of the hostname you specified.
Likely Causes
The hostname does not exist in the domain, or the name server in that domain is misconfigured.
Alternatively, you may have entered IPX or SNA addresses for the endpoint addresses.
Operator Action
Try one or more of the following:
Change the hostname to one that is known to exist in the name server.
If the host specified actually does exist, change the name server configuration to include
the searched for host.
Use the IP address (dotted notation) instead of the hostname.
Make sure youve selected the network protocol you want. You may have entered IPX or
SNA addresses for Endpoints 1 and 2, but forgot to change the network protocol from
TCP or UDP.
CHR0144
CHR0144: The hostname specified is unknown.
Explanation
An attempt was made to resolve the hostname that you provided, but the name server indicated it
could not be found. This can also occur if you specified a hostname without a domain name.
Operator Action
If the hostname specified contains a fully-qualified domain name, check and ensure that the domain
name is correct and that there is a name server running in that domain.
If only a hostname was specified, check that it is configured in the name server or in the local HOSTS
file.
CHR0145
CHR0145: The connection attempt timed out.
Explanation
Messages
133
An attempt was made to connect to an IP address. The TCP sockets library did not receive a response
within a preset timeout period.
Likely Causes
The partner is not active or there is no active route.
Operator Action
Use the TRACERT command on Windows NT or 95/98 (or TRACERTE in OS/2) to determine if
there is a break in the expected route to the partner. If TRACERT or TRACERTE shows that the route
extends all the way to the IP network of the partner, it is likely that the partner is simply not active.
CHR0146
CHR0146: The address is in a TCP/IP network that is unreachable.
Explanation
There is no route defined with which to reach the partner IP address.
Operator Action
Either define an explicit route to the partners IP network, or define a default link to your own
networks gateway or router.
CHR0147
CHR0147: An established TCP socket connection failed during processing.
Explanation
The active connection has been unexpectedly ended. Although it is possible that restarting the
Likely Causes
Here are some common causes for this error:
The partner is no longer active or there is no active route.
The endpoint program may have been stopped while it was running a test.
The network protocol stack aborted the connection, possibly because of data transmission
timeout or protocol error.
Operator Action
Retry the operation. If the failure persists, use the TRACERT command on Windows NT or 95/98 (or
TRACERTE in OS/2) to determine if there is a break in the expected route to the partner. If
TRACERT or TRACERTE shows that the route extends all the way to the IP network of the partner,
it is likely that the partner is simply not active.
134
CHR0148
CHR0148: The TCP/IP communications subsystem is not loaded.
Explanation
Either TCP/IP has not been installed, or it has not been configured properly.
Operator Action
Consult your TCP/IP manual for further assistance.
CHR0149
CHR0149: There is no remote program waiting to accept our TCP sockets connection.
Explanation
The partner computer rejected the sockets connection because the endpoint program was not running
on that computer, or the endpoint program has encountered an error.
This may also occur if too many connection requests are sent to an endpoint at the same time. In this
instance, the connection requests actually time out at the target endpoint and are rejected with the
same return value as if there was no program waiting.
Operator Action
On the partner computer, check that the endpoint program is still running. If it is, check if there are
any error log entries in the ENDPOINT.LOG file.
If the endpoint program is running and you get this error, consider attempting fewer connections to
this endpoint.
CHR0150
CHR0150: The buffer size specified (%1) is larger than the TCP sockets maximum buffer size (%2).
Explanation
allowed for TCP sockets.
Operator Action
protocol maximum.
CHR0151
CHR0151: The TCP port number is already in use.
Messages
135
Explanation
An attempt was made to accept a connection on a TCP port that the TCP sockets library believes is
already in use.
Likely Causes
This most often occurs when an endpoint program is stopped and then quickly restarted. The endpoint
is not always able to clear the socket that it uses. The TCP/IP library waits for 45-60 seconds after the
endpoint exits before it frees the port.
Operator Action
If the problem occurs on an endpoint program during its startup processing, simply wait for TCP/IP to
free the socket; the endpoint automatically retries the use of the socket.
If this problem occurs during a run, please contact Ganymede Software service. See Technical Support
CHR0152
CHR0152: OS/2 sockets library is not loaded. (Check that INET.SYS is set up correctly in
CONFIG.SYS.)
Explanation
The sock_init() call failed. This usually indicates that the OS/2 INET.SYS device driver was not
installed correctly.
Operator Action
Check your CONFIG.SYS file and ensure that there is a DEVICE= line that references a file named
INET.SYS.
CHR0153
CHR0153: Unknown TCP sockets failure.
Explanation
An unrecognized sockets failure has occurred.
Likely Causes
Unknown, as the failure was not recognized.
Operator Action
To solve the underlying problem, you must first find the TCP/IP errno value, which should be in a
second message returned along with this message. You need to look for this errno value in the
136
Software service and tell us about what error information you received and how it was generated. See
CHR0154
CHR0154: Sockets failure. errno is %1 on call %2.
Explanation
This provides additional information about an unknown sockets failure.
CHR0155
CHR0155: The supplied local address (%1) does not exist.
Explanation
An APPC address was specified for this computer that does not exist. This can only occur if the
Console to Endpoint 1 connection for this endpoint pair did not specify Use Endpoint 1 to Endpoint 2
values.
Operator Action
Correct the Endpoint 1 network address field of the Endpoint 1 to Endpoint 2 connection to specify an
APPC LU that exists on this computer.
CHR0156
CHR0156: The supplied local address does not exist. The network name in %1 did not match the local
network name (%2).
Explanation
An APPC address was specified for this computer that does not exist; it specifies an incorrect network
name.
For Chariot, this can occur if the Console to Endpoint 1 connection for this endpoint pair did not
specify Use Endpoint 1 to Endpoint 2 values.
For Pegasus, this can happen if an APPC address has been added to an endpoint, but the schedule is
delivered with another address (such as TCP/IP). If the APPC address doesnt actually exist on the
computer running the test, you see this message.
Operator Action
Correct the network name portion of the Endpoint 1 network address field to specify the correct
network name that is used by this computer.
Messages
CHR0157
CHR0157:
Opcode:
APPC primary return code:
APPC secondary return code:
Partner LU name:
Service Quality:
Partner TP name:
%1
%2
%3
%4
%5
%6
This provides detailed information about an APPC error.
CHR0158
CHR0158:
Opcode: %1
APPC primary return code: %2
APPC secondary return code: %3
CHR0159
CHR0159:
Opcode:
Local LU name:
Partner LU name:
Service Quality:
Partner TP name:
%1
%2
%3
%4
%5
%6
%7
CHR0160
CHR0160:
Partner address:
Service Quality:
Partner port number:
Sockets errno:
Call number:
%1
%2
%3
%4
%5
This provides detailed information about a TCP sockets error.
137
138
CHR0161
CHR0161:
Local address:
Partner address:
Service Quality:
%1
%2
%3
%4
This provides detailed information about a TCP sockets error.
CHR0162
CHR0162: Could not load a required DLL (%1).
Explanation
An attempt made to dynamically load a DLL failed. The name of the DLL is shown in the %1
variable.
Operator Action
If the operating system is OS/2, ensure that the named DLL is in a directory that is on the LIBPATH.
Remember that if you change the OS/2 LIBPATH in CONFIG.SYS, you must reboot to make the
change take effect.
If the operating system is Windows NT, the named DLL must be in one of these locations:
in one of the directories listed in the PATH environment variable.
in the same directory as the Chariot console, Pegasus server, or endpoint program
encountering the error.
in the SYSTEM32 subdirectory of the directory where Windows NT is installed (usually

either \WINNT35\SYSTEM32 or \WINNT\SYSTEM32).
CHR0163
CHR0163: Only one copy of the Chariot console can be active at a time.
Explanation
Chariot does not allow you to load two copies of the console program on one computer.
Operator Action
Using the Task List (Ctrl+Esc), find the Chariot program that is already running and either switch to
it, or end the program.
Messages
139
CHR0164
CHR0164: Cannot run a test without any endpoint pairs.
Explanation
You selected run for a test that does not have any endpoint pairs configured.
Operator Action
From the Test Setup window for this test file, select "Add an endpoint pair."
CHR0165
CHR0165: Only one test can be running at a time.
Explanation
A test is already running on this computer. Tests can be run using either the Chariot console or
RUNTST programs.
Operator Action
Find the copy of Chariot or RUNTST that is currently running a test and either stop the running test,
or wait for the test to complete.
CHR0166
CHR0166: The registration number is not valid for use with this evaluation copy.
Explanation
The registration number file, CHARIOT.REG, contains a registration number that is not valid for use
with evaluation copies.
Operator Action
Edit the CHARIOT.REG file in the Chariot executable programs directory and ensure that it contains
the registration number you obtained with your evaluation copy.
CHR0168
CHR0168: The APPC communications subsystem is not installed. No attempts to retry will occur. Ignore
this message if you are not using APPC.
Explanation
One of the DLLs that is shipped with APPC was not detected.
Operator Action
140
If the computer is running:
OS/2: install IBM Communications Server or Communications Manager/2.
Windows NT: install IBM Communications Server for Windows NT, IBM Personal
Communications, or Microsoft SNA Server.
Windows 95/98: install IBM Personal Communications.
CHR0169
CHR0169: The TCP/IP communications subsystem is not installed. No attempts to retry will occur. Ignore
this message if you are not using TCP/IP.
Explanation
One of the DLLs or NLMs that is shipped with TCP/IP was not detected.
Operator Action
If the computer is running OS/2, ensure that TCP/IP support is installed and configured correctly. If
the computer is running NetWare, ensure that TCPIP.NLM is loaded.
CHR0170
CHR0170: The APPC communications subsystem is not installed.
Explanation
One of the DLLs shipped with APPC is not found, when attempting to use APPC on the computer that
detected this problem.
If the computer that detected the problem is:
a Chariot console or Pegasus server: The current test attempted to use APPC for the
connection to Endpoint 1, even though APPC support is not installed.
an endpoint: The endpoint is configured to accept APPC connections, even though APPC
support is not installed.
Operator Action
Either APPC needs to be installed on the computer reporting the error, or the reason that APPC use
was attempted needs to be eliminated. Do one of the following depending on your situation.
Messages
141
Install APPC. If using OS/2, you need to install OS/2 Communications Manager. If the
computer is running Windows NT, you need to install IBM Communications Server,
IBM Personal Communications, or Microsoft SNA Server. If the computer is running
Windows 95/98, install IBM Personal Communications.
Edit the ENDPOINT.INI file so that it does not include the line ENABLE_PROTOCOL
APPC or ENABLE_PROTOCOL ALL
For Chariot, specify a supported protocol for the "console to E1" connection -- if the
Chariot console doesnt support APPC.
CHR0171
CHR0171: The TCP/IP communications subsystem is not installed.
Explanation
One of the DLLs that is shipped with TCP/IP is not found, when attempting to use RTP, TCP, or UDP
on the computer that detected this problem.
If the computer that detected the problem is:
a Chariot console or Pegasus server: The current test attempted to use TCP for the
connection to Endpoint 1, even though TCP/IP support is not installed.
an endpoint: The endpoint is configured to accept RTP, TCP, or UDP connections, even
though TCP/IP support is not installed.
Operator Action
If the computer is running OS/2, you need to install OS/2 TCP/IP.
CHR0172
CHR0172: An OS/2 write fault error occurred while attempting to write a file to disk in a temp directory.
The file could not be closed.
Explanation
Unable to write to this disk. The disk may be full. (It is likely that the target disk is a VDISK.) The
disk was selected for use in creating Chariot temporary files. To decide which directory to use for
temporary files, Chariot looks at:
1.
The GANYMEDE_TEMP environment variable
2.
The TMP environment variable
3.
The TEMP environment variable
4.
The directory in which the running program resides.
142
In addition, the file could not be closed. This means that you cannot erase the file until the
Chariot program ends.
Operator Action
Either change the GANYMEDE_TEMP environment variable to specify a different drive, clear some
files from the existing disk, or get a larger disk.
CHR0173
CHR0173: Out of disk space in a temp directory.
Explanation
While writing a file, an error was encountered indicating that the disk is full.
The disk was selected for use in creating Chariot temporary files. To decide which directory to use for
temporary files, Chariot looks at:
1.
The GANYMEDE_TEMP environment variable
2.
The TMP environment variable
3.
The TEMP environment variable
4.
The directory in which the running program resides.
Operator Action
Either change the GANYMEDE_TEMP environment variable to specify a different drive, clear some
files from the existing disk, or get a larger disk.
CHR0174
CHR0174: The TCP/IP network protocol stack ran out of a resource.
Explanation
While processing a TCP/IP sockets call, the TCP/IP stack ran out of a resource necessary to process
the call. The resource most likely to be exhausted is TCP/IPs internal buffers. It occurs more
frequently in tests where lots of short connections are started and stopped.
Operator Action
If the computer detecting the error was the Chariot console, modify the test to use fewer endpoint
pairs.
If the computer detecting the error was an endpoint, modify the test to use this computer fewer times.
Messages
143
If this error occurs on Windows 95, ensure you have the latest version of file KERNEL32.DLL from
Microsoft (2/2/96 or later). See our Web page for more details. This error may be followed by a trap
popup saying that the program has executed an illegal instruction. This is caused by the TCP/IP
stacks improper handling of sockets calls subsequent to the detection of the out-of-resource condition.
You should restart the endpoint program. If the problem recurs on the next test run, after changing it
as outlined above, you may need to reboot Windows 95.
If the endpoint computer is running UNIX, see the endpoint documentation for details on correcting
this condition.
CHR0175
CHR0175: The APPC network protocol stack is not supported.
Explanation
In this test, APPC was selected as the network protocol to be used either between a pair of endpoints
or for the connection to Endpoint 1. However, the APPC protocol is not supported by this version of
the software.
Operator Action
Contact Ganymede Software to ensure you have the latest version of the Chariot console, Pegasus
server, or endpoint program for the indicated operating system. Check to see if APPC is supported by
the current software.
CHR0176
CHR0176: The TCP network protocol stack is not supported.
Explanation
In this test, TCP was selected as the network protocol to be used between a pair of endpoints.
However, the TCP protocol is not supported by this version of the indicated endpoint program.
Operator Action
Contact Ganymede Software to ensure you have the latest version of the endpoint program for the
indicated operating system. Check to see if TCP is supported by the current endpoint software.
CHR0177
CHR0177: The IPX network protocol stack is not supported.
Explanation
In this test, IPX was selected as the network protocol to be used between a pair of endpoints. However,
the IPX protocol is not supported by this version of the indicated endpoint program.
Operator Action
144
indicated operating system. Check to see if IPX is supported by the current endpoint software.
CHR0178
CHR0178: The SPX network protocol stack is not supported.
Explanation
In this test, SPX was selected as the network protocol to be used between a pair of endpoints.
However, the SPX protocol is not supported by this version of the indicated endpoint program.
Operator Action
indicated operating system. Check to see if SPX is supported by the current endpoint software.
CHR0179
CHR0179: The UDP network protocol stack is not supported.
Explanation
In this test, UDP was selected as the network protocol to be used between a pair of endpoints.
However, the UDP protocol is not supported by this version of the indicated endpoint program.
Operator Action
indicated operating system. Check to see if UDP is supported by the current endpoint software.
CHR0180
CHR0180: Only one pair can be running at a time to this endpoint.
Explanation
This endpoint only supports one pair per test.
Operator Action
Change the test so that the indicated endpoint appears in only one endpoint pair.
CHR0181
CHR0181: Error creating a semaphore.
Explanation
An error occurred while attempting to create a semaphore.
Messages
145
Operator Action
Increase the number of semaphores available.
If the error was detected at a UNIX endpoint, it means that the endpoint program has run out of
system semaphores. Each instance of Endpoint 1 requires a system semaphore.
For AIX, Digital UNIX, and Sun Solaris, the maximum number of semaphores is not configurable; it
is hard-coded to a large value (4096). To avoid this problem, stop other programs which use
semaphores or decrease the number of tests which use the computer as Endpoint 1.
For HP-UX, use the SAM facility to increase the number of available system semaphores. Use the
procedure described above to change the following kernel configurable parameters: semmap, semmni,
semmns, and semmnu. After changing the kernel parameters, you must reboot HP-UX to have the
changes take effect. See the HP-UX System Administration Tasks manual for the definitions of these
parameters.
For Linux, each instance of Endpoint 1 requires a system semaphore. The maximum number of
semaphores is not configurable on Linux; it is hard-coded to a large value (128). To avoid this
problem, stop other programs which use semaphores or decrease the number of tests which use the
computer as Endpoint 1.
CHR0182
CHR0182: The partner and local addresses are the same. Loopback is not allowed.
Explanation
This endpoint cannot be both Endpoint 1 and Endpoint 2 in an endpoint pair because of one of the
following:
This endpoint does not support multiple threads or processes.
The communications software for the protocol chosen does not support loopback. This is
the case for APPC with SNA Server for Windows NT and for MVS.
Operator Action
Change one of the addresses to an address found on another computer, or if applicable, change to use
a different protocol.
CHR0183
CHR0183: The endpoint program is already running. Only one copy is allowed at a time.
Explanation
Only one copy of the endpoint can be run on a computer at a time. Although the current program
stopped running, the previously running endpoint continues unaffected.
Operator Action
146
Presumably you were trying to start an endpoint program. If so, theres nothing else you need to do -its already running. For information on stopping a running endpoint, see the chapter for the
corresponding operating system in the endpoint documentation.
CHR0184
CHR0184: WSAStartup() could not be initialized properly. The error code is %1.
Explanation
The WinSock call named WSAStartup() failed. This usually indicates that there was a problem
loading the WINSOCK.DLL.
Operator Action
Use the error code returned with this message to learn more about the problem. These error codes are
documented in the Microsofts Windows Software Development Kit (SDK), as well as later in this
message.
In addition, please contact Ganymede Software service so we can provide a better error message in
future versions of our software. See Technical Support for information on contacting Ganymede
Software.
If you are running the endpoint, stop the endpoint program after correcting the problem (for
information on doing this, see the chapter for the corresponding operating system in the endpoint
documentation), and restart it.
Here is some further assistance on the error codes:
10091: The WinSock implementation cannot function at this time because the underlying system it
uses to provide network services is currently unavailable.
Check that the WINSOCK.DLL file is in the current path.
Check that the WINSOCK.DLL file is from the same vendor as your underlying protocol
stack. You cannot mix and match (WINSOCK.DLLs must be supplied by the same
vendor that provided your underlying protocol stack).
You cannot use more than one WinSock implementation simultaneously. If you have
more than one WINSOCK.DLL on your system, ensure that the first one in the path is
appropriate for the network subsystem currently loaded.
Check your WinSock implementation documentation to ensure all necessary components

are currently installed and configured correctly.
CHR0185
CHR0185: This endpoint can only accept one test at a time.
Explanation
There are several combinations of Chariot consoles and Pegasus servers that can cause this condition.
Messages
147
Multiple Chariot consoles are attempting to run tests at the same time.
Multiple Pegasus servers are attempting to distribute schedules and tests to the endpoint
at the same time.
A Pegasus server is attempting to distribute schedules and tests to the endpoint while it is
already running a Chariot test.
Operator Action
Wait until the other Chariot console or Pegasus server is done using this endpoint or use another
endpoint.
CHR0186
CHR0186: The endpoints queue is being purged of all unusable timing records.
Explanation
Timing records cannot be returned to the Chariot console, so the endpoints queue is being purged of
all timing records for that console.
Operator Action
Restore communication to the console and rerun the test.
CHR0187
CHR0187: The partner program closed an APPC connection unexpectedly.
Explanation
After an APPC connection had been established, the partner program closed the connection. The
program that detected the error expected the partner to continue exchanging data on that connection.
Likely Causes
The partner program encountered an error while running a test, but could not report the error on the
connection being used for the tests. The most common example is if "validate data upon receipt" was
specified for the test, and data at Endpoint 2 did not validate correctly during the test.
Operator Action
Check the error log on the partner computer. It should contain an error log entry indicating the cause
of the problem. For example, if received data did not validate correctly, error CHR0242 messages will
be present on the partner computer -- indicating that data validation failed.
Follow the recommended Operator Action for the error messages found on the partner.
148
CHR0188
CHR0188: A report received out of sequence.
Explanation
Chariot keeps track of the report records received from each pair and verifies that all reports are
received in order and that none are lost. In this case, Chariot received a report record that was out of
sequence. This usually indicates that Endpoint 1 had previously been unable to send a report record,
possibly because of an intermittent network failure.
Operator Action
The test results are invalid and unrecoverable. Check the log file(s) on the Endpoint 1 computer.
Correct any problems indicated by the logs.
Rerun the test.
CHR0189
CHR0189: This spreadsheet file contains the maximum number of rows. Chariot wrote the file, but
omitted rows after 8192.
Explanation
Spreadsheet programs, like 1-2-3 and Excel, cannot read .WK3 files with more than 8192 rows. Your
spreadsheet file has been written; it contains the maximum of 8192 rows. Additional rows were not
written to the file. Some information from your test results has not been written to the spreadsheet file.
Operator Action
Consider creating tests results with fewer timing records. For example, increase the
transactions_per_record script variable while decreasing the number_of_timing_records. The test will
run for the same length of time, but produce fewer timing records.
CHR0190
CHR0190: An invalid program library encountered.
Explanation
Ganymede Software programs validate the shared libraries they require for their operation. One of
these shared libraries was unable to pass the validation tests. The program cannot operate until this
file is replaced with a valid one.
Operator Action
Reinstall the product from the original media, then reapply any service fixes that you had previously
applied.
Messages
149
CHR0191
CHR0191: Mismatch between function levels (Endpoint is %1, Console is %2).
Explanation
The Chariot console, Pegasus server, and endpoint programs are available in several functional levels.
For example, there are Evaluation, Demo, and Beta levels for some of these programs. These levels
generally have different capabilities, in some way, from the Retail version.
Your Ganymede Software product encountered a mismatch between the function level of the Chariot
console, Pegasus server, and the endpoint.
Operator Action
Your product software needs to be replaced with a compatible version. Please contact Ganymede
Software for sales assistance. See Technical Support for information on contacting Ganymede
Software.
CHR0192
CHR0192: Return code: %1
This provides the operating system return code associated with the reported condition.
CHR0193
CHR0193: This is a demo version. It only supports tests that run in the same computer.
Explanation
This demonstration version of the Chariot console is limited to running tests where both endpoints
have the same address.
Operator Action
The Endpoint 1 address must be the same as the Endpoint 2 address for all pairs in the test.
CHR0194
CHR0194: No local LU name has been set for the Chariot console.
Explanation
Chariot cannot determine the "Local LU Name" to use for APPC communications. It is either blank or
an error occurred while attempting to query it. If message CHR0192 accompanies this error, an
operating system return code will further diagnose the problem.
Operator Action
150
The LU name for Chariot is configured through the Windows Registry, by default it is set to
CHARIOT. Verify the Local LU Name is set correctly using the Registry Editor by running the
program REGEDT32.EXE from a command prompt. Find the Key:
\SnaBase\Parameters\TPs\GANYRPRT\Parameters and verify there is an entry as follows:
(Name=LocalLU Type=REG_SZ Data=CHARIOT.) The String CHARIOT is the LU alias Chariot
uses by default for the console programs local LU and should only be changed if absolutely necessary.
This will need to be changed if two consoles are run at the same time, since each console needs its
own unique LU alias rather than both using the default: CHARIOT.
CHR0195
CHR0195: The partner name specified is not recognized as a valid partner LU alias or fully-qualified
partner LU name.
Explanation
You specified a network address that was not configured on the computer which detected the error.
Likely Causes
For a network address, you specified either:
A partner LU alias, and this partner LU alias was not configured on the computer which
detected the error. Note that LU aliases are "case-sensitive." You may have entered the
wrong combination of uppercase and lowercase letters.
A fully-qualified partner LU name, and this LU name was not configured on the
computer which detected the error. This often happens with pre-APPN versions of APPC
(such as Windows NT SNA Server) which cannot search the network for fully-qualified
LUs. With these versions of APPC, all partner network addresses (LU names) must be
pre-configured.
Operator Action
Correct the network address by doing one of the following:
Specify a fully-qualified APPC network name that is defined on the computer which in
this case detected an error.
Specify the partner LU alias with the correct combination of uppercase and lowercase
letters.
Specify a partner LU alias that is defined on the console computer
Specify a partner LU alias that is defined on the computer which in this case detected an
error.
If the partner LU is defined and you are using a pre-APPN versions of APPC (such as
Windows NT SNA Server), ensure that the defined partner LU is "partnered" with the
local LU (that is, in the SNA Server Admin program, the LU 6.2 Partners LUs panel for
your local LU has a corresponding entry for the partner LU you are trying to contact.)
Messages
151
CHR0196
CHR0196: Your evaluation version has expired. You must obtain a registered version.
Operator Action
You must obtain a registered version of this product. Please contact Ganymede Software for sales
assistance. See Customer Service for information on contacting Ganymede Software.
CHR0197
CHR0197: The address %1 is an invalid IPX/SPX address.
Explanation
This endpoint pair contains a network address that is not a valid address for IPX/SPX. The network
address can be either:
an IPX address in hex (8 hex digits, a colon, and 12 hex digits), or
an alias from the IPX/SPX Alias List in the Edit IPS/SPX Entries option under Tools at
the Chariot console.
Operator Action
Either specify a valid IPX address or an alias from the consoles IPX/SPX directory. Valid IPX
addresses contain a 4-byte network ID followed by a 6-byte node ID. The network ID and node ID are
separated by a colon. An example of a valid IPX address is 03AF8934:0A024F345678.
CHR0200
CHR0200: The %1 connection attempt timed out.
Explanation
An attempt was made to connect to an %1 address. The sockets library did not receive a response
within a preset timeout period.
One computer was unable to reach another using the sockets API. For example, a TCP/IP Ping to the
target computer will probably fail. (Contrast this with message CHR0204, which is returned when the
target computer can be reached but the endpoint program is not available there.)
Likely Causes
Here are some frequent causes for this error:
The network address doesnt exist. You may have entered the wrong letters or digits in
the network address.
The target computer is not active.
The protocol stack on the target computer is not active.
152
There is no active route to the target computer.
The network or partner computer is too busy to reply within the timeout period.
Operator Action
Use the TRACERT command on Windows NT or 95/98 (or TRACERTE in OS/2) to determine if
there is a break in the expected route to the partner. If TRACERT or TRACERTE shows that the route
extends all the way to the IP network of the partner, it is likely that the partner is not active or that
youre using an invalid network address.
If youre using Chariot and you feel you can skip this endpoint, uncheck the "Stop on initialization
failure" checkbox, in the Run Options dialog, to bypass this endpoint and continue running.
CHR0201
CHR0201: The address is in a %1 network that is unreachable.
Explanation
There is no route defined with which to reach the partner %1 address.
If the protocol is SPX, this may also mean that there was no remote program waiting to accept our
SPX connection. The partner computer may have rejected the connection because an endpoint
program was not running on that computer, or the endpoint program has encountered an error.
Operator Action
Either define an explicit route to the partners %1 network, or define a default link to your own
networks gateway or router.
If the protocol is SPX, check that the endpoint program on the partner computer is still running. If it
is, see if there are related error log entries in the ENDPOINT.LOG file.
CHR0202
CHR0202: An established %1 connection failed during processing.
Explanation
The active connection has been unexpectedly ended. Although it is possible that restarting the
Likely Causes
The partner is no longer active or there is no active route.
The endpoint program may have been stopped while it was running a test.
Messages
153
The network protocol stack aborted the connection, possibly because of data transmission
timeout or protocol error.
Operator Action
Retry the operation. If the failure persists and RTP, TCP, or UDP is the protocol, use the TRACERT
command on Windows NT or 95/98 (or TRACERTE in OS/2) to determine if there is a break in the
expected route to the partner. If TRACERT or TRACERTE shows that the route extends all the way to
the IP network of the partner, it is likely that the partner is simply not active.
CHR0203
CHR0203: The %1 communications subsystem is not loaded.
Explanation
Either %1 has not been installed, or it has not been configured properly.
Operator Action
Consult your manual for further assistance.
CHR0204
CHR0204: There is no remote program waiting to accept our %1 sockets connection.
Explanation
The partner computer rejected the sockets connection because an endpoint program was not running
on that computer, the endpoint program has encountered an error, or the endpoint program was
unable to process all of the incoming connections within the timeout period.
One computer was able to reach its partner computer successfully; for example, a TCP/IP Ping to that
computer will probably succeed. Its the endpoint program on the partner thats not available.
(Contrast this with message CHR0200, which is returned when the partner computer cannot be
reached at all.)
Operator Action
On the partner computer, check that the endpoint program is still running. If it is, see if there are
related error log entries in the ENDPOINT.LOG. If it has stopped and there is an ASSERT.ERR file,
please contact Ganymede Software service. See Technical Support for information on contacting
Ganymede Software.
If youre using Chariot and you feel you can skip this endpoint, uncheck the "Stop on initialization
failure" checkbox, in the Run Options dialog, to bypass this endpoint and continue running.
CHR0205
CHR0205: The buffer size specified (%1) is larger than the %2 sockets maximum buffer size (%3).
154
Explanation
allowed for %2 sockets.
Operator Action
protocol maximum. See DEFAULT Values for the Endpoints for the values used on each endpoint
operating system.
CHR0206
CHR0206: The %1 port number is already in use.
Explanation
An attempt was made to accept a connection on a %1 port that the %1 library believes is already in
use.
Likely Causes
This most often occurs when an endpoint program is stopped and then quickly restarted. The endpoint
is not always able to clear the handle that it uses. There may be 45-60 second delay after the endpoint
exits before it frees the port.
Here are some other possible causes:
Another running application, like FTP, has bound to this port.
The Chariot console or Pegasus server itself has bound to this port, for use in setting up
tests.
This pair is using a datagram protocol: IPX or UDP. Only one pair at a time can use a
port number for each datagram protocol. For example, only one pair at a time can use
UDP with port number 1234 between an endpoint pair; however, another pair can be
using IPX with port number 1234.
Some endpoints only allow one pair at a time with the same port number. These
endpoints are HP-UX (before version 3.0), Linux (before version 3.0), and MVS.
The Multicast Group contains multiple pairs that use more than one of the following
three addresses as Endpoint 2:
localhost
127.0.0.1
the IP address for the Endpoint 2 computer
Operator Action
If the problem occurs on an endpoint program during its startup processing, simply wait for the
communications handle to be freed; the endpoint automatically retries the accept attempt.
Messages
155
Otherwise, stop the application that has bound the port, or change your test setup to use unique port
numbers on different pairs. If this problem still occurs during a run, please contact Ganymede
Software service. See Technical Support for information on contacting Ganymede Software.
CHR0208
CHR0208: Unknown %1 communications failure.
Explanation
An unrecognized communications failure has occurred.
Likely Causes
Unknown, as the failure was not recognized.
Operator Action
To solve the underlying problem, you must first find the communications errno value, which should be
in a second message returned along with this message. You need to look for this errno value in the
Software service and tell us about what error information you received and how it was generated. See
CHR0209
CHR0209: The %1 address is not available.
Explanation
The Endpoint 1 or Endpoint 2 network address is not available.
Likely Causes
The address specified for Endpoint 1 does not exist on the computer specified by "How does the
Console know Endpoint 1?"
Operator Action
Ensure that the address specified for Endpoint 1 exists on the computer specified in "How does the
Console know Endpoint 1?"
CHR0210
CHR0210: The %1 network protocol stack ran out of a resource.
Explanation
156
While processing a %1 API call, the %1 stack ran out of a resource necessary to process the call. The
resource most likely to be exhausted is %1s internal buffers. It occurs more frequently in tests where
lots of short connections are started and stopped.
Operator Action
If the computer detecting the error was the Chariot console, modify the test to use fewer endpoint
pairs.
If the computer detecting the error was an endpoint, modify the test to use this computer fewer times.
If this error occurs on Windows 95, ensure you have the latest version of file KERNEL32.DLL from
Microsoft (2/2/96 or later). See our Web page for more details. This error may be followed by a trap
popup saying that the program has executed an illegal instruction. This is caused by the %1 stacks
improper handling of sockets calls subsequent to the detection of the out-of-resource condition. You
should restart the endpoint program. If the problem recurs on the next test run, after changing it as
outlined above, you may need to reboot Windows 95.
If the endpoint computer is running UNIX, see the endpoint documentation for details on correcting
this condition.
CHR0211
CHR0211:
Partner address:
Service Quality:
Communications errno:
Call:
%1
%2
%3
%4
%5
This provides detailed information about a communications error.
CHR0212
CHR0212: Sense data is 08050000. The requested session cannot be activated because the session limit
has been reached.
Explanation
CHR0127.)
Operator Action
See the sense code documentation for SNA sense data 08050000 for more information.
Messages
157
CHR0213
CHR0213: Your beta version has expired. You must obtain a registered version.
Operator Action
You must obtain a registered version of this product. Please contact Ganymede Software for sales
assistance. See Customer Service for information on contacting Ganymede Software.
CHR0214
CHR0214: RC received while waiting to accept a connection, verify APPC Attach Manager is active.
Explanation
While waiting to accept a connection, a return code was received indicating a problem with the state
of the APPC stack. Either the APPC Attach Manager wasnt started or the APPC stack wasnt fully
started.
Operator Action
Verify that the APPC Attach Manager is started.
For OS/2, ensure there is a START_ATTACH_MANAGER statement in the (.NDF)

node definitions file, and verify the Attach Manager is active -- with the Subsystem
Management program.
For Windows NT using SNA Server, verify that the server is active by using the SNA
Server Admin program.
For Windows NT using IBM Communications Server or for Windows NT or Windows

95/98 using IBM Personal Communications verify the Attach Manager is started by
using the SNA Node Operations program and viewing the Operations...Attach Manager
Started menu item.
CHR0215
CHR0215: Mismatch between datagram support levels (Console does not support datagrams)
Explanation
The endpoint supports datagram protocols, but the Chariot console does not.
Operator Action
The Chariot console needs to be replaced with a version which supports datagram protocols. Please
contact Ganymede Software for sales assistance. See Customer Service for information on contacting
Ganymede Software.
158
CHR0216
CHR0216: Data not received within the timeout period (%1 milliseconds)
Explanation
A datagram connection failed because data sent by the partner was not received within the timeout
period.
When using reliable datagram delivery, the timeout period is the Retransmission Timeout "times" the
Number of Retransmits before Aborting. For streaming scripts, the timeout period is the Receive
Timeout value.
Likely Causes
The configured timeout period is too short or the network is too congested.
The configured timeout period is too short or the network is too congested. If you are
running a streaming script, data could also have been lost.
If you are executing a streaming script, the Receive Timeout period may be too short. If
no data is received, the initial timeout period is two minutes.
You are using a Chameleon TCP/IP stack (from NetManage Inc.) with the UDP protocol
on Windows 3.1, and your send buffer size is more than 1490 bytes.
If you are running a test with a multicast group, the Time To Live (TTL) value may be
too low. The TTL must be more than one for the packet to leave the subnetwork.
Operator Action
From the Main window, go to Options and select the Change User Settings menu item. On the
Datagram tab, increase the Retransmission Timeout and Number of Retransmits parameters. If you
are executing a streaming script, increase the Receive Timeout parameter.
If youve hit the bug in the Chameleon stack, the workaround is to either modify the script to send less
than 1490 bytes at a time or use a different TCP/IP stack. Weve seen this bug with versions 4.6.5,
4.6.6, and 7.0 of the Chameleon TCP/IP stack for Windows 3.1.
If you are running a test with a multicast group and the TTL value is 1, from the Main Window, go to
Options and select the Change User Settings menu item. On the Datagram tab, increase the Time To
Live (TTL) value to a number greater than one.
CHR0217
CHR0217: An acknowledgment not received within the timeout period (%1 milliseconds)
Explanation
A datagram connection failed because the partner did not send an acknowledgment within the timeout
period.
Messages
159
The timeout period is the Retransmission Timeout "times" the Number of Retransmits before
Aborting.
Likely Causes
The configured timeout period is too short or the network is too congested.
Operator Action
In the Datagram options menu, increase the Retransmission Timeout and Number of Retransmits
parameters.
CHR0218
CHR0218: The local LU name your software attempted to use is not defined.
Explanation
The local LU which was attempted to use is not an LU that the APPC subsystem has defined. The
local LU to be used is determined differently depending on where the error was reported. If the error
was reported by:
Chariot console or Pegasus server: the local LU for Windows NT SNA Server is defined
in the Windows Registry when the console is installed, and unless changed by the user, it
is set to be "CHARIOT".
An Endpoint: the local LU is defined during installation or at a later time using the
SETALIAS.EXE program.
Operator Action
Verify that the Local LU Name shown in the accompanying log matches a local LU name or alias
defined for the system reporting the error. For example: on Windows NT using SNA Server, use the
SNA Server Admin program to verify that a local LU exists with the name reported in the log
message.
CHR0219
CHR0219: The %1 address (%2) is not available.
Explanation
The Endpoint 1 address %2 does not exist on the computer specified by "How does the Console know
Endpoint 1?" This could also occur because the fully qualified address could not be obtained by the
endpoint when attempting to connect to another endpoint.
Likely Causes
The address specified for Endpoint 1 does not exist on the computer specified by "How does the
Console know Endpoint 1?" Also, we have seen cases where the stack rejects an attempt to use the
address due to severe stress conditions. In particular, we have seen this when running a large number
of short connection tests in a loopback manner.
160
Operator Action
Ensure that the address specified for Endpoint 1 exists on the computer specified in "How does the
Console know Endpoint 1?" If this address exists, decrease the amount of stress by reducing the
number of pairs running on this endpoint.
CHR0220
CHR0220: The datagram size specified (%1) is larger than the %2 maximum buffer size.
Explanation
The script that was run specified a buffer size for SEND that was larger than that allowed for %2.
Some of the application scripts cannot be run using IPX without changes to their buffer sizes. With
some scripts (such as FTPGET, FTPPUT, and POP3), IPX on a medium (such as Ethernet) has a
maximum buffer size which is less than their default send_buffer_size. IPX is unable by its design to
break up the buffer so that it will run on the medium.
Operator Action
Edit the endpoint pair on which this error occurred and decrease the buffer size to the amount allowed
by the network protocol stack. For example, to run one of the scripts discussed above on Ethernet with
IPX, edit the script to reduce the send_buffer_size to 1458 or less.
CHR0221
CHR0221: A newer version of Chariot created the test file.
Explanation
You are trying to load a test file created by a newer version of Chariot than the one youre using. The
version youre using does not know how to load the newer file format.
Operator Action
Use the newer version of Chariot to use this test file.
CHR0222
CHR0222: A newer version of Chariot created the script.
Explanation
You are trying to load a script file shipped with a newer version of Chariot than the one youre using.
The version youre using does not know how to load the newer file format.
Operator Action
Use the newer version of Chariot to use this script file.
Messages
161
CHR0223
CHR0223: WinAPPCStartup() failed with error code %1. Your APPC stack is not active.
Explanation
The WinAPPCStartup() call failed. This usually indicates that the underlying APPC network
subsystem is not ready for network communications.
Likely Causes
On Windows NT with Microsoft SNA Server, this is usually caused when the SnaBase service cannot
be started, such as when it is set to Disabled using the Control Panel Services program. On other
platforms this means that there is no active configuration.
Operator Action
For SNA Server, use the Control Panel Services program to verify that the SNA Server service
SnaBase is not set to Disabled. For IBM Communications Server or IBM Personal Communications
products run the SNA Node Operations program and start the node.
CHR0224
CHR0224: Unsupported Windows APPC stack "%1". This software only supports Microsoft SNA Server
for NT, IBM Communications Server for NT, and IBM Personal Communications for NT and 95.
Explanation
Your product software attempted to load the APPC protocol stack but found an unsupported APPC
stack with a description as noted in the error message.
Operator Action
The supported Windows APPC stacks are currently:
Microsoft SNA Server for Windows NT "Server"
Microsoft SNA Server for Windows NT "Client for Windows NT"
IBM Communications Server for Windows NT (Server computer only)
IBM Personal Communications for Windows NT or Windows 95
If multiple SNA stacks are present on the computer, the PATH environment variable may need to
be modified to ensure the directory containing the correct WAPPC32.DLL file is listed before
directories containing any other versions of WAPPC32.DLL.
CHR0225
CHR0225: The %1 address is unreachable, the endpoint is not started, or the endpoint does not support
the requested function.
162
Explanation
The connection request can not be completed to the partner. This can occur because
the endpoint is not running,
the endpoint cannot be reached through the network at this time,
the Endpoint 1 address is a local address (i.e., 127.0.0.1) and the Endpoint 2 address is
not,
the endpoint does not support the protocol being used, or
the endpoint contacted does not support the base functionality needed to operate with
Pegasus. This program will not be able to run tests to this endpoint until it is upgraded.
Operator Action
Ensure the host is accessible, the endpoint program has been started, and that it supports the network
protocol used in the test.
If these conditions have all been met, you may need to upgrade the identified endpoint to the latest
level of endpoint software.
CHR0226
CHR0226: Interrupted %1 function call.
Explanation
A communications function call was interrupted and the active connection has been ended. Although
it is possible that restarting the connection could be successful, this failure disrupts the validity of test
results, and thus is always flagged as an error.
Likely Causes
There are too many applications running concurrently on the system or there are not enough network
communication stack resources to satisfy applications requests.
Operator Action
Reduce the number pairs using that endpoint.
This error occurs on Windows 95/98 when you run more pairs than are supported by the Windows
95/98 network communications stack.
CHR0227
CHR0227: No LU name is configured for the endpoint.
Explanation
Messages
163
Chariot cannot determine the "LU Name" to use for receiving APPC communications from SNA
Server. It is either blank or an error occurred while attempting to query it. If message CHR0192
accompanies this error, an operating system return code provides further diagnostic information.
Operator Action
The LU name for Windows endpoints is configured through the use of the SETALIAS program.
Running SETALIAS with no parameters shows the current local LU alias the endpoint uses, as well
as any errors encountered accessing this information. Running SETALIAS with an LU alias as the
only parameter instructs the endpoint to use that specified LU alias.
CHR0228
CHR0228: Conflicting LU aliases defined. TP %1 uses %2 but TP %3 uses %4.
Explanation
While determining the local LU name for Chariots use, conflicting information was found in the
system configuration.
Operator Action
Resetup the LU information. The LU name for Windows endpoints is configured through the use of
the SETALIAS program. Running SETALIAS with no parameters shows the current local LU alias
the endpoint uses, as well as any errors encountered accessing this information. Running SETALIAS
with an LU alias as the only parameter instructs the endpoint to use that specified LU alias.
CHR0229
CHR0229: Exhausted pool of defined APPC TPs. Only %1 concurrent APPC tests may be run to this
endpoint as Endpoint 2.
Explanation
More APPC test pairs were attempted to concurrently run on this endpoint as Endpoint 2 than this
endpoint can handle.
Operator Action
Run fewer APPC tests concurrently with this endpoint as Endpoint 2. This may require lowering the
number of tests run, or alternately, changing some of the pairs in the test to use this computer as
Endpoint 1.
CHR0230
CHR0230: "%3" is not a valid command (in %1 at line %2).
Explanation
The text string indicated in %3 was found in the ENDPOINT.INI where a command is expected.
164
Because an error was encountered in the ENDPOINT.INI file, no Chariot consoles or Pegasus servers
are allowed to run tests with this endpoint.
Operator Action
Check the proper syntax for ENDPOINT.INI command and edit the ENDPOINT.INI file.
Stop the endpoint and restart it, using the updated ENDPOINT.INI file. The ENDPOINT.INI file is
described in the endpoint documentation.
CHR0231
CHR0231: %3 appears more than once (in %1 at line %2).
Explanation
The command indicated in %3 appears more than once in the ENDPOINT.INI file. It may only be
used once.
Operator Action
Edit the ENDPOINT.INI file and remove one of the instances of this command.
CHR0232
CHR0232: Parameter(s) missing on %3 command (in %1 at line %2).
Explanation
The command indicated in %3 requires a parameter and none was supplied.
Operator Action
Check the documentation for the proper syntax for this command and edit the ENDPOINT.INI file
appropriately.
CHR0233
CHR0233: Line too long (in %1 at line %2).
Messages
165
Explanation
The ENDPOINT.INI file contains a line that is too long (more than 255 characters). This may be due
to a corrupted or overwritten ENDPOINT.INI file.
Operator Action
Correct the indicated line in the ENDPOINT.INI file, or start from scratch with a new
ENDPOINT.INI file.
CHR0234
CHR0234: Too many parameters for %3 command (found "%4" in %1 at line %2).
Explanation
The command indicated in %3 requires fewer parameters than were supplied.
Operator Action
appropriately.
CHR0235
CHR0235: "%3" is not a valid parameter for the %4 command (in %1 at line %2).
Explanation
The parameter indicated in %3 is not valid for the command indicated in %4.
Operator Action
appropriately.
166
CHR0236
Explanation
The parameter indicated in %3 is not valid for the command indicated in %4.
Operator Action
appropriately.
CHR0237
CHR0237: %3 found after %4 %5 command (in %1 at line %2).
Explanation
The command indicated in %3 is not valid after the command indicated in %4 and %5.
Operator Action
appropriately.
CHR0238
CHR0238: Missing address parameter for the %3 command (in %1 at line %2).
Explanation
The command indicated in %3 requires an address parameter that was not supplied.
Operator Action
appropriately.
Messages
167
CHR0239
CHR0239: %4 %5 found after %3 command (in %1 at line %2).
Explanation
The command is not valid after the command indicated in %3.
Operator Action
appropriately.
CHR0240
CHR0240: The address (%4) on the %3 command is too long (in %1 at line %2).
Explanation
The address indicated in %4 is too long. Addresses must be less than or equal to 64 bytes long.
Operator Action
Edit the ENDPOINT.INI file, using a network address that is of the proper length.
CHR0241
CHR0241: The endpoint does not allow tests from this Chariot console or Pegasus server (using the %1
protocol and an address of %2).
Explanation
The endpoint is not configured to allow tests from this Chariot console or Pegasus server.
Operator Action
Edit the ENDPOINT.INI on the computer which detected this error.
168
If you are not using ALLOW ALL, check that the "ALLOW protocol" specifies the
correct address for this console or server. The address is indicated in the audit log (you
may need to turn on SECURITY_AUDITING to turn on auditing).
Stop the endpoint and restart it, using the updated ENDPOINT.INI file. The ENDPOINT.INI file
is described in the endpoint documentation.
CHR0242
CHR0242: Data received does not validate correctly.
Explanation
A running test which had the "validate data upon receipt" run option specified received data from the
partner endpoint that failed validation. Either the data was corrupted by the network, or the data files
used to send and receive data (that is, those files in the endpoints cmpfiles\ subdirectory) are not the
same on both endpoints of the failed test.
Operator Action
Verify that the files in the cmpfiles\ subdirectory are identical on both endpoints of the failed test. A
mismatch can most likely occur when USERxx.CMP files were created and used for the test, but were
not identical on both endpoints.
If the files are identical, an error occurred in the network that corrupted the data that was sent. This
will require further diagnosis -- most likely with a data analyzer.
CHR0243
CHR0243: Endpoint %1 is not running or is incorrectly configured. Another endpoint (%2) received this
session.
Explanation
The computer rejected the incoming APPC Attach because the endpoint program was not running on
that computer, or the endpoint program has encountered an error.
Likely Causes
The endpoint program is not running.
In OS/2, the APPC Attach Manager associated with the partner LU is stopped. This can
be caused by a missing START_ATTACH_MANAGER statement in the
Communications Manager (.NDF) node definitions file.
If your Console to Endpoint 1 protocol is not APPC and your Endpoint 1 to Endpoint 2
protocol is APPC, you may need to fully qualify your E1 and E2 addresses so that the
console does not attempt to resolve the APPC address. For example: LU1 would become
NETA.LU1
Operator Action
Messages
169
On the computer returning this error, check that the endpoint is running. If it is, check if there are any
error log entries in the ENDPOINT.LOG file.
CHR0244
CHR0244: The %3 protocol is not supported by this endpoint (in %1 at line %2).
Explanation
The protocol indicated in %3 is not available on this platform or is not supported by this endpoint.
Operator Action
Check the documentation for the list of protocols supported by this endpoint.
CHR0245
CHR0245: The partner program closed the %1 socket connection unexpectedly.
Explanation
After a connection had been established, the partner program closed the connection. The program that
detected the error expected the partner to continue exchanging data on that connection.
Likely Causes
The partner program encountered an error while running a test, but could not report the error on the
connection being used for the tests. The most common example is if "validate data upon receipt" was
specified for the test, and data at Endpoint 2 did not validate correctly during the test.
This error can occur when using IPX or UDP. If theres a lot of traffic on the network, datagrams are
lost. The endpoints will retransmit, but if things get bad enough that all the retransmissions are lost,
the endpoints eventually time out.
This error occurs when the send_buffer_size is greater than the endpoints internal buffer size. For
example, in the FTPGET and FPTPUT scripts, the send_buffer_size and receive_buffer_size is set to
4,096, rather than DEFAULT -- to emulate the real FTP application. With IPX, the DEFAULT value
on all endpoints is either 537 or 1,391. FTPGET and FTPPUT cannot run using IPX without
changing the send_buffer_size.
If you are using MVS, LINUX, Sun Solaris or Windows 3.1 as one of the endpoints in a pair and are
testing through a proxy firewall you might get this error. These Operating Systems do not support
using port correlation for scripts with more than one connection as they do not support abortive closes.
Operator Action
Check the error log on the partner computer. It should contain an error log entry indicating the cause
of the problem. For example if data did not validate correctly, error CHR0242 messages will be
present on the partner computer -- indicating that data validation failed.
If you suspect datagrams are being lost,
170
1.
Increase the Retransmission Timeout or the Number of Retransmits before Aborting

(both of these are Run Options).
2.
Use Batch reporting, instead of real-time. This can substantially reduce the amount of
network traffic.
For any protocol, be sure the send_buffer_size is less than or equal to the endpoints actual buffer size.
Follow the recommended Operator Action for the error messages found on the partner endpoint.
CHR0246
CHR0246: File doesnt exist or is zero length.
Explanation
A data file Chariot attempted to use has a file length of zero or does not exist.
Likely Causes
The file was corrupted or truncated by a program other than Chariot.
The file was changed (written to) by another program while this program was reading it.
Operator Action
Use a backup copy of the file. There is no way to recover a file that has been corrupted or truncated to
zero length.
CHR0247
CHR0247: The APPC Mode Name specified is either invalid or not a configured mode name.
Explanation
The mode name is either not configured or is not valid for the partner LU specified.
Likely Causes
You specified an incorrect mode name in the Service Quality field of the test pair in error.
Operator Action
Select a mode name from those currently configured at both LUs in the test.
CHR0249
CHR0249: A broken pipe encountered while redirecting output.
Explanation
Messages
171
This command was run with its output piped to another process. That process ended before this
command did.
Operator Action
Usually, this is caused by pressing Ctrl+C or Ctrl+Break, ending the piped process. No intervention is
required.
CHR0250
CHR0250: The LU alias is invalid. An LU alias must be 1-8 characters long.
Explanation
The LU alias specified must be from 1 to 8 characters long.
Operator Action
Specify a valid LU alias. Try configuring all the LU aliases on SNA Server first before defining them
here. This helps ensure that all the aliases are valid.
CHR0251
CHR0251: Could not load a required NLM (%1).
Explanation
An attempt to dynamically load a NetWare Loadable Module (NLM) failed. The name of the NLM is
shown in the %1 variable.
Operator Action
Ensure the named NLM is installed in the location specified in the error message.
CHR0252
CHR0252: Could not load required function (%1).
Explanation
An attempt to dynamically access a function failed. The name of the function is shown in the %1
variable.
Operator Action
This could happen if the required NLMs or DLLs are from different levels. Ensure that all endpoint
NLMs or DLLs are from the same build level. Issuing the MODULES commands at the NetWare
console shows the version of all loaded NLMs. Either rebooting or reinstalling and rebooting should
restore NLMs or DLLs to the same level.
172
CHR0253
CHR0253: Errors occurred trying to process the timing records received from Endpoint 1.
Explanation
A timing record that was sent by Endpoint 1 was rejected by the Chariot console or Pegasus server.
This is usually due to a severe error that causes the software to be out of sync.
Operator Action
Rerun the test.
CHR0254
CHR0254: The IPX/SPX communications subsystem is not installed. No attempts to retry will occur.
Ignore this message if you are not using IPX/SPX.
Explanation
An NLM needed for IPX/SPX to run was not loaded. This can occur when IPX/SPX support is not
installed on the computer.
Operator Action
Ensure that TLI.NLM and SPXS.NLM are loaded on the NetWare Server.
To avoid seeing this message at endpoints where IPX/SPX is not installed, change the following line
in the ENDPOINT.INI file:
ENABLE_PROTOCOL ALL
to enable only the protocols actually installed on that computer. The ENDPOINT.INI file is described
in the Performance Endpoints manual.
CHR0255
CHR0255: The endpoint does not allow tests from any Chariot console or Pegasus server.
Explanation
The endpoint is not configured to allow tests from any Chariot console or Pegasus server.
The most likely cause is an error in the ENDPOINT.INI file at the endpoint.
Operator Action
Edit the ENDPOINT.INI on the computer which detected this error.
Check the ENDPOINT.LOG file for errors processing ENDPOINT.INI, which may have
caused the endpoint to reject all requests.
Messages
173
Stop the endpoint and restart it, using the updated ENDPOINT.INI file. The ENDPOINT.INI file
is described in the Performance Endpoints manual.
CHR0256
CHR0256: An endpoint LU alias name (%1) is not known by the Chariot console or Pegasus server.
Explanation
An APPC LU alias was used for an endpoint network address. Either APPC is not installed on the
Chariot console or Pegasus server computer, or no APPC alias with the name given is in the APPC
configuration.
Another possible cause is that the endpoint may have been restricted from using APPC in the
ENDPOINT.INI file.
Operator Action
Do one of the following:
Change the endpoints alias name to match a configured APPC alias.
Use fully-qualified LU names for Endpoint 1 and Endpoint 2 to remove the need for the
Chariot console or Pegasus server to convert LU aliases to fully-qualified LU names. Do
not specify APPC as the protocol used to connect to Endpoint 1 if APPC is not installed
on the console or server computer.
See your APPC product manual for information on defining LU aliases.
CHR0257
CHR0257: The APPC Subsystem abended. User intervention may be required to restart.
Explanation
The Chariot console or Pegasus server received notification that its local APPC subsystem encountered
an internal error and has abended. The console or server may be stuck forever waiting for the APPC
subsystem to respond. Follow the operator actions below to ensure the APPC subsystem is returned to
normal processing.
Likely Causes
If detected on a Windows NT computer using SNA Server, the SNA Server became overloaded and
failed, often with event 706 logged on the SNA Server computer. This indicates that SNA Server
cannot keep up with the traffic load and has aborted the connection to the client. This condition is
most prevalent in connections between two SNA Server Client computers.
Operator Action
Examine the error log to determine the reason for the abend. First check which computer detected the
error. See Determining Which Computer Detected an Error for information about how to determine
this.
174
If the computer is running OS/2, check the FFST log on the computer returning the error, to
determine the cause as reported by Communications Manager.
If the computer is running Windows NT, check the Windows NT Event Log on the computer
detecting the error, or if using SNA Server, on the computer where the SNA Server "Server" is
installed. There should be events logging the failure that occurred.
Occasionally, SNA Server does not correctly notify both sides of the conversation and will leave one
side active and the other side inactive. In this case, the Console does not return to a normal stopped
state (that is, the status line doesnt report Stopped). In this case, manually deactivate the conversation
using the SNA Server Administration program. Using this program, select the consoles LU from the
list by double clicking on it, (the Chariot console uses an LU named CHARIOT by default), click the
"Status..." button, locate the partner LU and mode used for the "Console to Endpoint 1" connection
and click the "Zoom" button to display all conversations that are still active. If any are listed, select
them one at a time and click on the "Deactivate" button. When you have finished, the Chariot console
should return to a normally-stopped state.
CHR0258
CHR0258: Unable to write %1.
Explanation
An attempt to write a GIF associated with an HTML file failed.
Likely Causes
Here are the most likely causes for this error.
The monitor is set to display more than 256 colors.
The target drive is out of disk space.
Operator Action
Do one of the following:
Set the color palette to 256 colors or less.
Make space on the target drive or save to another disk.
CHR0259
CHR0259: Unexpected printer error.
Explanation
The operating system returned an error while attempting to print.
Likely Causes
This error is generally caused by an incorrectly-installed printer driver.
Messages
175
Operator Action
Consider one of these actions:
Consider selecting another printer from the list of available printers.
Check the viability of the current printer driver or reinstall the printer driver.
CHR0260
CHR0260: Sense data is 08400007. An APPN directory request cannot locate the partner computer.
Explanation
CHR0127.)
Operator Action
CHR0261
CHR0261:
Opcode:
VTAM RTNCD and FDB2:
APPC sense data:
Partner LU name:
Service Quality:
Partner TP name:
%1
%2
%3
%4
%5
%6
%7
%8
CHR0262
CHR0262:
Opcode:
APPC sense data:
%1
%2
%3
%4
%5
CHR0263
CHR0263:
176
Opcode:
APPC sense data:
Local LU name:
Partner LU name:
Service Quality:
Partner TP name:
%1
%2
%3
%4
%5
%6
%7
%8
%9
CHR0264
CHR0264: Port number %1 is already in use.
Explanation
The specified port number has already been bound by another application.
Likely Causes
Here are some possible causes:
Another running application, like FTP, has bound to this port.
The Chariot console or Pegasus server itself has bound to this port, for use in setting up
tests.
This pair is using a datagram protocol: IPX or UDP. Only one pair at a time can use a
port number for each datagram protocol. For example, only one pair at a time can use
UDP with port number 1234 between an endpoint pair; however, another pair can be
using IPX with port number 1234.
Some endpoints only allow one pair at a time with the same port number. These
endpoints are HP-UX (before version 3.0), Linux (before version 3.0), and MVS.
Operator Action
Stop the application that has bound the port, or change your test setup to use unique port numbers on
different pairs.
CHR0265
CHR0265: Sense data is 08570003. A VTAM LU is not active or the endpoint on MVS is not running.
Explanation
CHR0127.)
Most likely you are attempting to use a mainframe based endpoint that is not active.
Operator Action
Messages
177
CHR0266
CHR0266: An attempt to start an APPC session for a mode that is past the session limit.
Explanation
A new APPC session was being activated when this error occurred. Activating this session would
exceed the negotiated session limit for the mode being used.
Likely Causes
This error is because more pairs were attempted than could be handled by the current APPC
configuration.
Operator Action
View the mode limit configuration on the computers at both sides of the attempted session. Since the
mode limits are negotiated down to the lowest value of either side, either one side or both will need to
be adjusted.
See the Chariot consoles User guide, "Defining Modes for Large APPC Tests" for information about
circumventing session limit problems.
CHR0267
CHR0267: The MVS VTAM interface for APPC did not initialize correctly. Reason = %1.
Explanation
The open VTAM ACB request did not complete successfully.
Likely Causes
This can occur because the VTAM APPLIDs specified in the JCL EXEC parameters are not defined
or active to VTAM.
The reasons for failure are:
1.
Invalid name for APPLID
2.
Getmain for ACB storage failed
3.
GENCB for ACB failed
4.
Open failed for ACB
5.
SETLOGON failed for ACB
6.
INTERNAL: ACB name not found
7.
INTERNAL: Status = TPEND
178
Operator Action
Ensure the ACB names are defined in SYS1.VTAMLST and varied active. Some useful information
may be provided on the MVS operator console. See the endpoint documentation, "Using Multiple
ACB Names (LU Names)" for information on activating an APPL segment on VTAM -- even if youre
only using one ACB name.
CHR0268
CHR0268: You must be the root user to run this command.
Explanation
The endpoint command can only be run by the root user.
Likely Causes
You are not logged into the UNIX system as the root user.
Operator Action
Log in or "su" to the root user and retry the command.
CHR0269
CHR0269: The %1 receive request timed out.
Explanation
An Endpoint 2 was contacted to begin a test but did not receive all the necessary information to begin
the test within a 15 minute period.
Likely Causes
Here are some frequent causes for this error:
The test was abandoned during initialization.
Endpoint 1 was unable to contact the Endpoint 2 during test setup.
CHR0270
CHR0270: Error creating a shared memory identifier.
Explanation
An error occurred while attempting to get a shared memory identifier.
Likely Causes
This error probably occurred because a file was too big to be loaded into shared memory. The file is
specified by the send_datatype variable in the script for this test pair.
Messages
179
Operator Action
Increase the maximum shared memory segment size or use a different send_datatype.
CHR0271
CHR0271: Performance problem. Scheduled test skipped because previous test still running.
Explanation
An endpoint has skipped a scheduled Pegasus test because the test was still running from a previous
time period.
Likely Causes
There are several potential causes:
The test script associated with the test has been modified to send so much data or run so
many timing records that it now takes longer to run that the configured testing interval is
set to.
A major change in network performance is now causing a previously valid test to run
longer than the configured testing interval. For example a test that is scheduled to run
every minute on a T1 link might normally takes 2 seconds to execute, but if the T1 link
fails and a 33.6K modem line takes over, the test will now take over 60 seconds to run
and will interfere with the next scheduled test time.
A protocol stack is excessively slow determining a failure.
The endpoint or a network connection it is using is overcommitted to the point where

multiple tests for the same connection are overlapping.
The clock time on Endpoint 1 or the engine has been changed drastically, causing tests
that were scheduled to run during the time delta to get skipped.
Operator Action
Examine the script, normal execution time, and configured test interval values for the connection in
question. Either shorten the amount of data or number of timing records in the script, or lengthen the
interval between tests. Also examine the number of tests being run on the endpoint in question and
remove some if excessive.
CHR0272
CHR0272: The remote endpoint contacted does not support Pegasus functions.
Explanation
The endpoint that was contacted does not support the base functionality needed to operate with
Pegasus. This program will not be able to run tests to this endpoint until it is upgraded.
Likely Causes
180
The endpoint has not been upgraded from a Chariot-only endpoint to the level required to support
Pegasus.
Operator Action
Upgrade the identified endpoint to the latest level of endpoint software.
If the endpoint is confirmed to be at the latest level, consult message CHR0122 for further diagnostic
information.
CHR0274
CHR0274: The Pegasus database is not responding.
Explanation
Pegasus Configuration is unable to communicate with the Pegasus Database Server.
Likely Causes
The Pegasus Database Server has not completed initialization. There is one likely cause (and one
unlikely cause):
The Pegasus server starts four NT Services when you restart Windows NT. These may
take up to two minutes to load fully. If you try to do Pegasus Configuration immediately
after rebooting, you may get this message, which says that the database has not been
started.
There is an internal error in Pegasus, which is causing the database to fail.
Operator Action
Exit Pegasus Configuration, wait a minute or so, then try again.
If this doesnt work, there may be an internal failure. Please contact Ganymede Software service. See
CHR0275
CHR0275: A Pegasus component is exceeding its retry count and can not be restarted. The component is
"%1".
Explanation
The Pegasus Server service restarts its subcomponents and required services if they should fail. If they
fail too often in too short a time, they are not restarted and this error is generated.
Likely Causes
The subcomponent has encountered system errors or has program bugs.
Operator Action
Messages
181
Check the error logs for the underlying causes. See Viewing Error Logs for information on error logs.
CHR0276
CHR0276: The Pegasus server is running low on disk space. (Space available is %1 percent.)
Explanation
The drive on which the Pegasus server is installed is running low on disk space. This message is first
displayed when available disk space is reduced to 10%, and is repeated at 5%, 4%, 3%, 2%, and 1%
remaining available disk space.
Likely Causes
The Pegasus database, where results and reports are stored, has used up almost all the available disk
space on the Pegasus servers drive.
Operator Action
Free up disk space by removing non-Pegasus data from the partition that contains the Pegasus
database. Delete disabled connections (or enabled connections no longer in use). Deleting connections
causes their performance results to be discarded, which will free up disk space. Move the database to
another drive, following the steps described in the chapter called "Administering the Pegasus
Database" in the Pegasus User Guide.
CHR0277
CHR0277: Performance problem. Scheduled test skipped because it is past time to run next test.
Explanation
An endpoint has skipped a scheduled Pegasus test because it is already past time to run the next test
for the same connection.
Likely Causes
The test script associated with the test has been modified to send more data or run more
timing records than before. The current test configuration now takes longer to run than
the test interval. (the number of minutes between test runs).
A major change in network performance is now causing a previously valid test to run
longer than the configured testing interval. For example a test that is scheduled to run
every minute on a T1 link might normally takes 2 seconds to execute, but if the T1 link
fails and a 33.6K modem line takes over, the test will now take over 60 seconds to run
and will interfere with the next scheduled test time.
A protocol stack is excessively slow determining a failure.
The endpoint or a network connection it is using is overcommitted to the point where

multiple tests would overlap.
182
On Windows 3.1, since multiple scheduled tests are run synchronously, this connection
may have been affected by other tests that ran slowly or had errors.
The clock time on Endpoint 1 or the engine has been changed drastically, causing tests
that were scheduled to run during the time delta to get skipped.
Operator Action
Examine the script, normal execution time, and configured test interval values for the connection in
question. Either shorten the amount of data or number of timing records in the script, or lengthen the
interval between tests. Also examine the number of tests being run on the endpoint in question and
remove some if excessive.
CHR0278
CHR0278: Pegasus database is not responding.
Explanation
The Pegasus database server is not responding to requests.
Likely Causes
There are three potential causes:
The most likely cause is that the Pegasus database server is not running.
A second potential cause is that there is no valid network path to the Pegasus database
server, or the user has specified an incorrect network path.
You were disconnected by another user.
Operator Action
Restart the Pegasus database server using the Services Control Panel. Restore a valid network
path to the Pegasus database server. Exit Pegasus Configuration and sign on again.
CHR0279
CHR0279: One or more Pegasus services are not available.
Explanation
The Pegasus server, Pegasus database server, and/or the Web server used by Pegasus are not
available.
Likely Causes
One or more of three Windows NT services (Pegasus server, Pegasus database server, or the
Web server used by Pegasus) is not running.
Operator Action
Messages
183
Open the Services Control panel and restart the Pegasus server, Pegasus database server, and
World Wide Web Publishing Service. You can also restart the Web server using the
Microsoft Internet Service Manager (restart the "WWW" service).
CHR0280
CHR0280: Unable to start Pegasus Configuration; access denied or host is unknown.
Explanation
The Pegasus Configuration contacted the Pegasus Web server to authenticate your user name
and password. The authentication process failed or the Web server could not be reached.
Likely Causes
Incorrect password.
Your user name was not prefixed with a domain name.
Your user name was not defined in the Pegasus Administrators group.
Windows NT has locked your user account out.
The IP address for the Pegasus Web server is not valid.
The port number for the Pegasus Web server is not valid.
There is no valid network path to the Pegasus Web server.
The Pegasus Web server is not running.
The Pegasus Web server does not exist.
The Pegasus Web server is busy.
The Web server is installed, but the Pegasus server is not installed on
the target computer.
Operator Action
Check that the Windows NT user name and password you are using are valid. Ensure that
you have prefixed the user name with a domain name and \ (for example,
"ganymede\johnq"). Ensure that the user name has been added to the Pegasus Administrators
group at the Pegasus server computer. If necessary, reset the user account. Ensure you have a
valid address and port number for the Pegasus server (the usual port number for Web servers
is 80). Restore a valid network path to the Pegasus server.
At the Pegasus server computer, open the Services program in the Windows NT Control
Panel, and restart the Pegasus Database Server service and World Wide Web Publishing
Service. You can also restart the Web server using the Microsoft Internet Service Manager
(restart the "WWW" service).
184
CHR0281
CHR0281: The MVS VTAM interface encountered an internal error. Reason = %1.
Explanation
The endpoint has encountered an internal error while working with VTAM.
Likely Causes
21: Queue processing error while deleting TP
31: 0-length TP name during Define TP
32: TP name length error during Define TP
Operator Action
Most of these errors indicate "should not occur" conditions which cannot be affected by
operator action. Some useful information may be provided on the MVS operator console.
Please contact Ganymede Software service. See Technical Support for information on
CHR0282
CHR0282: Due to previous errors on the Security Audit file, the audit function is now disabled.
Explanation
The endpoint has encountered an unrecoverable file system error while writing security audit
data.
Likely Causes
Disk Full
User File Limit exceeded
File allocation limit exceeded
Permanent I/O error on disk
Operator Action
Additional information may be available from operating system logs. Check to see if
hardware problems are indicated.
Otherwise, make space available for the audit file by moving it to a different device or
partition, by deleting other files, or by increasing allocation limits.
Messages
185
CHR0283
CHR0283: The specified service quality can not be satisfied for the connection.
Explanation
The service quality that was specified for the test could not be satisfied by the service
provider.
Likely Causes
The values specified in the service quality template cannot be satisfied under
current network conditions.
The service quality template name does not exist on the endpoint.
Operator Action
Modify the values configured for the service quality template or the template name.
Otherwise, run the test again to see if the network can now satisfy the specified service
quality.
CHR0284
CHR0284: An error occurred while running a service quality test.
Explanation
An error was reported by the service quality provider. The error number can be found in the
detailed error message information.
Likely Causes
An error occurred due to lack of network resources.
There was a problem with some of the values in the service quality template.
Operator Action
To solve the underlying problem, you must first find the communications error value, which
should be in a second message returned along with this message. You need to look for this
errno value in the appropriate platform documentation.
CHR0285
CHR0285: The endpoint could not join the multicast group with multicast address %1 and
network address %2.
186
Explanation
An error was reported by the TCP/IP stack when the endpoint tried to join the IP Multicast
group.
Likely Causes
The endpoint was using localhost or 127.0.0.1 for the endpoint network address. Using
localhost also causes the TCP/IP stack to return errno 10055.
Operator Action
Check that the Endpoint 1 or Endpoint 2 address is not localhost or 127.0.0.1. Windows NT 4.0 and
above, Windows 95/98, and Linux do not allow these addresses to be used when joining an IP
Multicast group.
CHR0286
CHR0286: This program requires Microsofts WinSock 2 support.
Explanation
The Windows 95 console requires that WinSock 2 be installed for TCP or SPX support.
Operator Action
The WinSock 2 stack may be downloaded from Microsofts Web site. Alternatively, consider using
Windows 98, which has a more mature version of WinSock 2 built in.
CHR0287
CHR0287: The authorization key entered does not match the registration number and license code.
Explanation
The authorization key you entered is not valid.
Operator Action
Ensure that the authorization key you entered is the same as the authorization key you received from
the Ganymede Software Registration Center.
For retail versions, you must register the product with the Ganymede Software Registration Center to
receive an authorization key. Contact information for the Ganymede Software Registration Center can
be found on the inside of your product CD-ROM case. You may use this software in evaluation mode
while you are requesting your authorization key. The evaluation period is 15 days for Chariot and 30
days for Pegasus.
Upon contacting the Ganymede Software Registration Center, you will be asked for a registration
number and a license code. The registration number can be found on the Registration Card you
received upon purchase. For existing customers, the license code is provided on the initial screen
displayed when starting the product. After providing this information to the Registration Center, you
will receive an authorization key that will activate the retail version of the product.
Messages
187
For evaluation versions, leave the registration number field empty. Each time you start the product,
the dialog displays the number of days remaining in the evaluation period. After the evaluation period
is over, you will not be able to start the product without entering a registration number and
authorization key. If you later purchase the product, obtain an authorization key, as described above,
and use the registration number provided by your sales representative. You do not have to reinstall the
software after you purchase the product.
If the authorization key does match and this problem persists, please contact Ganymede Software
Customer Care. See Technical Support for information on contacting Ganymede Software.
CHR0288
CHR0288: Invalid Application Scanner input
Explanation
A script cannot be generated from API calls stored in TRACE.BIN.
Likely Causes
The TRACE.BIN file located in the Script Generator directory is corrupted. The TRACE.BIN file
stores all WinSock API calls made during the trace. The Application Scanner uses the API calls stored
in this file to create a script.
Operator Action
Try the trace again. If the problem persists contact Ganymede Software Customer Care and send them
the TRACE.BIN file. See Technical Support for information on contacting Ganymede Software.
CHR0289
CHR0289: The application being traced has multiple simultaneous socket connections.
Explanation
The application had more than one connection active at the same time.
Operator Action
Either limit the application transaction to one active connection when the trace is performed, or
specify a destination port if the transaction can limited to a specific port.
CHR0290
CHR0290: This transaction has both TCP and UDP connections.
Explanation
Datagram traffic and connection-oriented traffic are both present in this transaction.
Operator Action
188
Use the destination port to limit the script to either the UDP (datagram) traffic or the TCP
(connection-oriented) traffic.
CHR0291
CHR0291: Sends or receives found outside of an existing connection.
Explanation
Sends or receives were in this transaction from a previously established connection.
Likely Causes
The application established a connection before the transaction being traced, and is sending data over
the connection. The trace was either started too early or traced too many calls.
Operator Action
Either trace a shorter application transaction or trace a longer application transaction based on the
send and receives in the application transaction.
CHR0292
CHR0292: The traced application set up UDP connections with multiple destinations.
Explanation
The application transaction being traced is communicating with multiple destinations. Datagrams are
being sent to or received from multiple destinations.
Operator Action
Limit the application transaction to one destination.
CHR0293
CHR0293: The captured trace has too many commands to create a script.
Explanation
The captured trace resulted in more than 1300 commands. The Application Scanner cannot create a
script. Chariot 2.2 cannot load scripts with more than 1300 commands. Pegasus 1.1 cannot load
scripts with more than 150 commands.
Operator Action
Evaluate the application transaction traced and try to break the transaction into multiple application
transactions. Restart the Application Scanner wizard and create a trace for each application
transaction. If one of the scripts generated is still too long, try to break the transactions down even
further. You can then use the multiple scripts to test the application tasks.
Messages
189
CHR0294
CHR0294: A script cannot be generated from the WinSock API calls recorded in the TRACE.BIN file.
Explanation
The trace did not contain WinSock API calls that would result in a script. A connection must be
established or data must be sent and received to create a script.
Likely Causes
There are two potential causes:
A CONNECT WinSock call was not issued on the port specified on the Change User
Settings dialog.
The application that you were tracing did not make any CONNECT, SEND, or
RECEIVE WinSock calls in the trace.
Operator Action
If you are using port filtering either deselect the Select a port to trace option on the Change User
Settings dialog or change the port that you are tracing.
If you are not using port filtering or if making these changes does not produce a script, restart the
trace and perform a transaction that includes one of these WinSock calls. You may also need to
increase the length of the trace.
CHR0295
CHR0295: The application being traced made an Accept API call.
Explanation
The application is receiving incoming connections. Scripts can only be created for programs that
initiate connections.
Operator Action
If possible, limit the application transaction so the commands are not present. Trace the application on
the initiating side instead of the receiving side.
CHR0296
CHR0296: An unexpected error occurred.
Explanation
A system error occurred.
Likely Causes
An internal error.
190
Operator Action
Refer to the TRACE.LOG error file for information on the error. Please send the error file to
Ganymede Software Customer Care. See Technical Support for information on contacting Ganymede
Software.
CHR0297
CHR0297: The file or path name being used by the Application Scanner is too long.
Explanation
The file or path name being used by the Application Scanner is too long.
Likely Causes
A directory or file name of TRACE.BIN was too long.
Operator Action
Please contact Ganymede Software Customer Care so we can provide a better error message in future
versions of our software. See Technical Support for information on contacting Ganymede Software.
CHR0301
CHR0301: A process not found error occurred.
Explanation
A process ID could not be found. The process selected did not make any WinSock calls.
Likely Causes
A process ID search failed.
Operator Action
There is an internal error. Please contact Ganymede Software Customer Care. See Technical Support
CHR0302
CHR0302: The process, %1, no longer exists or could not be opened.
Explanation
An OpenProcess call was made on a process ID which did not exist, or could not be opened.
Likely Causes
A process or application that you selected to trace was terminated.
Messages
191
Operator Action
Because the Application Scanner can only trace a specific instance of a program, you must restart the
program and then use the wizard to set up another trace.
Select another process to trace.
CHR0303
CHR0303: The file TRACE.BIN could not be deleted.
Explanation
The TRACE.BIN file could not be deleted.
The Layered Service Provider (LSP) records all WinSock API calls made during a specific trace in the
TRACE.BIN file. Before a TRACE.BIN file can be created for a trace, the TRACE.BIN file for the
previous trace must be deleted.
Likely Causes
The Layered Service Provider has not closed the TRACE.BIN file from a previous trace.
The file cannot be deleted if the file is in use.
Another application is using the TRACE.BIN file. The file cannot be deleted if the file is
in use.
Operator Action
Close all applications that you were previously tracing and all applications that could be using the
TRACE.BIN file. The Layered Service Provider should then close the TRACE.BIN file. You can now
restart your new trace.
CHR0304
CHR0304: An error occurred using WinSock 2.
Explanation
WinSock 2 is not installed correctly on the computer.
Operator Action
There is an internal error. Please contact Ganymede Software Customer Care so we can provide a
better error message in future versions of our software. See Technical Support for information on
192
CHR0305
CHR0305: Could not find or load GCAPTURE.DLL or GCAPOUT.DLL.
Explanation
The Layered Service Provider is not installed. A script cannot be created unless the Layered Service
Provider is installed correctly.
Likely Causes
The Layered Service Provider was manually uninstalled from the computer.
The installation was not successful and the Layered Service Provider was not installed.
Operator Action
Reinstall the Application Scanner.
CHR0307
CHR0307: There was a problem opening or writing to TRACE.BIN. The error code is %1.
Explanation
There was a problem opening or writing to TRACE.BIN. The error code is %1.
Likely Causes
The disk is full or the TRACE.BIN file cannot be accessed. For example, the file is write protected.
Error code 112 means that TRACE.BIN is being written to a disk that is full.
Operator Action
Verify that the disk contains enough space to create the TRACE.BIN file. If necessary, free some
space.
If the disk contains enough space, send the TRACE.LOG file to Ganymede Software Customer Care.
See Technical Support for information on contacting Ganymede Software.
CHR0308
CHR0308: An internal error occurred in the Layered Service Provider for the application that you are
tracing. The source file is %1 and the line number is %2.
Explanation
An internal error occurred in the Layered Service Provider for the application that you are tracing.
Operator Action
Messages
193
Please contact Ganymede Software Customer Care and provide us with the source file and line
number where the error occurred. See Technical Support for information on contacting Ganymede
Software.
Exit the Application Scanner and the application you are tracing. Use the wizard to set up a new trace
and trace the transaction again.
If this doesnt work, reinstall the Application Scanner. This will reinstall the Layered Service Provider
and may fix the error.
CHR0309
CHR0309: The combination of Application Script and schedule on connection %1 is too large to send to
the endpoint.
Explanation
The size of the Application Script plus schedule information has exceeded the size that can be sent to
the endpoint.
Likely Causes
Your schedule looks too much like a checkerboard. That is, it has a large number of noncontiguous
timing squares selected.
Operator Action
Modify the schedule to have longer blocks of time and increase the test interval accordingly.
Alternatively, you can select one of the Pegasus preset schedules.
CHR0310
CHR0310:
Partner address:
Service Quality:
Communications errno:
Call:
%1
%2
%3
%4
%5
%6
This provides communications call stack information about an unexpected communications error.
CHR0311
Explanation
"%3" is not a valid number of milliseconds for the %4 command.
194
Operator Action
Edit the ENDPOINT.INI file to supply a number of milliseconds between 0 and 2,147,483,647.
Stop the endpoint and restart it, using the updated ENDPOINT.INI file.
Index
195
Index
A
accept() call in Sockets, 7, 10
ALLOCATE call in APPC, 7
APPC mappings of script commands, 7
application script commands, 12
application script name, 14
application scripts, 1
B
Bader benchmarks, 2
benchmark scripts, 2
bind() call in Sockets, 7, 10
BKWBSIGN script, 24
BKWBUPDT script, 26
business scripts, 5
C
Calgary Corpus, list of files, 21
CASTDL script, 28
CASTINIT script, 30
checkpoint, 13
Cisco Systems IP/TV audio, 67
Cisco Systems IP/TV video, 69
classic transactions, 2
close() call in Sockets, 7, 10
CMP files, 21
command rules, 15
communications commands, 6
compression, 21
CONFIRM call in APPC, 7
CONFIRMED call in APPC, 7
CONN script, 32
connect() call in Sockets, 7, 10
constant value, 16
CREDITL script, 33
CREDITS script, 35
D
DBASEL script, 37
DBASES script, 39
DEALLOCATE call in APPC, 7
DEFAULT values for the endpoints, 11
E
END_LOOP script command, 13
END_TIMER script command, 13
exponential distribution, 19
F
FILERCVL script, 41
FILERCVS script, 43
FILESNDL script, 45
FILESNDS script, 46
FLUSH call in APPC, 7
FTPGET script, 47
FTPPUT script, 51
G
G723, 71
H
H261, 73, 75, 99
HDLNINIT script, 55
HDLNUPDT script, 57
HTTPGIF script, 59
HTTPTEXT script, 61
I
INCREMENT_TRANSACTION script command, 13
INQUIRYL script, 63
INQUIRYS script, 65
Internet scripts, 3
IP Multicast, 5
IPTVA script, 67
IPTVV script, 69
L
listen() call in Sockets, 7, 10
listings of Application scripts, 2, 3, 23
LOOP script command, 13
Lotus Notes, check for unread e-mail, 80
Lotus Notes, receive e-mail, 82
Lotus Notes, send e-mail, 84
196
M
Microsoft NetMeeting audio, 71
Microsoft NetMeeting video, 73
Microsoft NetShow, 75
MPA, 67
MPV, 69
N
NETMTGA script, 71
NETMTGV script, 73
NETSHOWU script, 75
network news transfer protocol, 77
NNTP script, 77
NOCOMPRESS, 21
normal distribution, 18
NOTESCHK script, 80
NOTESRCV script, 82
NOTESSND script, 84
P
Packet Blaster, long receive, 88
Packet Blaster, long send, 86
PACKETL script, 86
PACKETLR script, 88
parameter rules, 15
PCMA, 114
PCMU, 114
PNTCAST1 script, 90
PNTCAST2 script, 92
PointCast Network, 90, 92
Poisson distribution, 18
POP3 script, 94
program control script commands, 13
Push scripts, 4
script file name, 23

script rules, 13
script variable rules, 16
scripts
benchmark, 2
business, 5
Internet, 3
Push, 4
streaming, 5
send data rate, 19
SEND_DATA call in APPC, 7
SLEEP script command, 13
sleep times, 16
uniform distribution, 18
SMTP script, 109
socket() call in Sockets, 7, 10
Sockets mappings of script commands, 7, 10
START_TIMER script command, 13
streaming scripts, 5
summary of scripts, 2
T
t_bind() call in TLI, 10
t_connect() call in TLI, 10
t_open() call in TLI, 10
t_rcv() call in TLI, 10
t_rcvudata() call in TLI, 10
t_snd() call in TLI, 10
t_sndudata() call in TLI, 10
TELNET script, 112
TLI mappings of script commands, 10
TP_STARTED call in APPC, 7
U
R
random sleep times, 16
REALAUD script, 97
REALMED script, 99
RealNetworks RealAudio, 97
RealNetworks RealMedia, 99
RECEIVE_ALLOCATE call in APPC, 7
RECEIVE_AND_WAIT call in APPC, 7
repeat, loop, 13
S
SAPAUTHP script, 101
SAPINV script, 103
SAPLOGIN script, 105
SAPPUROR script, 107
UNLIMITED, 5, 19
USER01.CMP through USER10.CMP, 21
V
voice over IP, 114
VOIPS script, 114
W
Web Push scripts, 4
Z
ZEROS, 16, 21
Application Scanner User Guide, version 1.2
(July 1999)
Copyright Ganymede Software Inc., 1995-1999. All rights reserved.
1100 Perimeter Park Drive Suite 104
Morrisville, North Carolina 27560-9119
U.S.A.
Web: http://www.Ganymede.com/
ii
Contents
iii
Contents
Introducing Application Scanner
Whats New in Application Scanner 1.2.................................................................................. 1

Known Limitations ................................................................................................................. 2
Use Our Extensive Online Help ............................................................................................. 2
Installing Application Scanner
Hardware/Software Requirements ......................................................................................... 5

Installing the Application Scanner .......................................................................................... 5
Actions during the Application Scanner Installation................................................................. 6
Removing the Application Scanner (Uninstall) ........................................................................ 7
Working with Application Scanner
How Application Scanner Works ............................................................................................ 9

Before Creating a Script ...................................................................................................... 10
Special Cases When Tracing Datagram Packets .................................................... 11
Selecting the Application...................................................................................................... 11
Script Optimization .............................................................................................................. 12
Understanding Streams ....................................................................................................... 14
Main Window ......................................................................................................... 15
Tracing a Program: Active or Not Active ................................................................. 17
Choosing an Active Application or Process ............................................................. 17
Specifying an Executable Filename ........................................................................ 18
Completing the Trace ............................................................................................. 18
Working with the Script Editor
21
Editing a Parameter of a Script Command ........................................................................... 22

Editing a Script Variable ...................................................................................................... 22
The File Menu (Script Editor) ............................................................................................... 23
Adding a New Script ............................................................................................... 23
Saving a Script ....................................................................................................... 24
The Edit Menu (Script Editor)............................................................................................... 25
The Insert Menu (Script Editor)............................................................................................ 28
Script Editor Keys Help........................................................................................................ 29
Troubleshooting
31
Viewing the Error Log .......................................................................................................... 31

Reading Error Messages ..................................................................................................... 31
Common Problems.............................................................................................................. 32
An Application Cannot Run After the Application Scanner is Installed...................... 32
iv
Ganymede Software Customer Care
33
Customer Service................................................................................................................ 33
Troubleshooting Guidelines ................................................................................................. 33
How to Get Technical Support ............................................................................................. 34
Index
35

Predefined scripts emulating many network applications are shipped with Ganymede Software products
and are available on the Web. Scripts permit extensive customization. For example, you can modify the
value assigned to a script variable such as file_sizethe bytes in the transferred fileor the number of
repetitions of a transaction between endpoints.
If you find that some applications you want to emulate are not currently included in the library of
predefined scripts, you can use Application Scanner to create application scripts that meet your specific
needs. Application Scanner lets you create scripts based on a traced transaction, without having to
understand the scripting language. An Application Scanner dialog guides you through the process of
tracing an application or process and generating a script. You can save the script for use in Chariot 2.2
and later versions, or in Pegasus 1.2 and later versions.
During Application Scanner installation, the Script Editor program is also installed. Use the Script Editor
to modify any script: either predefined scripts or scripts generated by Application Scanner. You can
launch the Script Editor from the Application Scanner folder on the Start menu. You can also use the
Script Editor to create a new script by using one of its script templates. See Working with the Script
Editor on page 21 in the Working with Script Editor chapter for more information. The Script Editor is
also part of Chariot 2.2 and later versions.
Whats New in Application Scanner 1.2

Application Scanner version 1.2 lets you create scripts for a much broader range of applications than
earlier versions. We think you will also find it much easier to use.
Application Scanner can now capture a trace for complex transactions containing multiple simultaneous
connections. The application being traced can be both the source and destination for connections. You
can generate scripts for any or all of the traced connections. For example, most Web browsers establish
multiple connections to a Web server, using port 80. You can choose the connection for which you want
to create a script. See Understanding Streams on page 14 in the Working with Application Scanner
chapter for more information.
Script optimization is performed when needed, to keep the number of SEND and RECEIVE commands
small (under around 1,000); this makes the script easier to manipulate in Chariot and Pegasus. By
default, Send and Receive pairs of the same size are compressed. Additionally, Send and Receive sizes
within specified ranges and averages are combined to decrease the script size. Application Scanner lets
you know how much optimization was performed, if any, on all scripts that are created. See Script
Optimization on page 12 in the Working with Application Scanner chapter for more information.
It is now easier to identify which process needs to be traced. A new column in the Application Selection
dialog shows the last time a WinSock call was made for each active application or process. This list can
be sorted by time or application/process name. A new Refresh button lets you see if anything has changed
recently.
You can save and open the traces created by Application Scanner. The binary trace file can be saved and
reloaded later. You can use the trace files for understanding the types of stresses that they place on your
network. You can identify the trace files by their default file extension of .AST.
Known Limitations
Application Scanner version 1.2 has the following limitations. We will continue to increase the range of
applications for which Application Scanner can create scripts.
Scripts can only be created for applications that use TCP or UDP
The WinSock API only supports TCP and UDP protocols so these are the only type of applications
that Application Scanner supports.
Only traces WinSock API calls, on Windows 95, 98, or NT

Application Scanner only works with applications that make WinSock calls on Windows 95, 98, or
NT. Application Scanner does not trace application calls that bypass the WinSock API. For
example, remote file access through Explorer bypasses the WinSock API, so Application Scanner can
not create a script for this application.
Conflicts with some applications on Windows NT 4 with Service Pack 3

Application Scanner causes conflicts with applications containing the WinSock calls ReadFile and
WriteFile on Windows NT 4 with Service Pack 3. For example, Microsofts IIS and Peer Web
Services use these calls. You must install Windows NT Service Pack 4 or later to use an application
with these calls. In addition, we have found that there is a memory leak in Service Pack 3 when
using Application Scanners LSP. This defect is fixed in Service Pack 4. If you are using Windows
NT 4 with Service Pack 3, we recommend that you install Application Scanner, collect the traces that
you need and then uninstall Application Scanner. On Windows NT 4, we support Application
Scanner running with Service Packs 3, 4, or 5, but we recommend using Service Pack 4 or later.
Application Scanner will not coexist with Microsoft Proxy Client

Application Scanner uses the Layered Service Provider to capture WinSock API calls. Microsofts
Proxy uses its own Layered Service Provider and the two will not coexist. So you should not install
the Application Scanner on the same computer where the Proxy Client product is installed.
Generated scripts ignore QoS information

Application Scanner traces GQOS API calls related to Quality of Service (QoS) for TCP/IP, but
cannot incorporate the QoS information into a script.
Requires an Uninstall and Re-install if you add a new protocol stack

If you add a new protocol stack to the computer, it is required that you Uninstall and Re-install
Application Scanner. This is because the new protocol installation will reorder the protocol layers,
which can possibly disable the installed protocol.
Use Our Extensive Online Help

Ganymede Software products come with an extensive online help system. When you select a help button
in a dialog, the appropriate topic in the appropriate manual is shown with information about that dialog.
While in the online help, you can also select other topics, and the Web browser will transfer you to the
appropriate section of the documentation.
Heres how to find what you need in our online help.
The Home button, at the top of each chapter, takes you to the online library. From there, you can
select any of the online books.
The Index button, at the top of each chapter, takes you to the index for the current online book. You
can scroll through the alphabetized index, or you can use your browsers text search feature (click
Edit/Find in Microsofts Internet Explorer or Netscapes Navigator/Communicator) to move more
quickly through the index.
Each book has a table of contents at the left. Click on any chapter name to read it.
Each chapter has a table of contents at the top. Click on a section name to jump to it. Use your
browsers scroll bars to move through the text.

During installation, both Application Scanner and the Script Editor program are installed. The online
Help is also installed for Application Scanner, Script Editor, the Scripts manual and the Messages
Reference. These can all be access by pressing the Help buttons or pressing the Help icon.
Hardware/Software Requirements
Heres what you need to run the Application Scanner:
One of the following operating systems:

Windows NT 4.0 with Service Pack 3 or later. We recommend Service Pack 4 or later.
Windows 98
Windows 95 with WinSock 2
You can download WinSock 2 for Windows 95 from the Microsoft Web site at
http://www.microsoft.com/windows95/downloads/contents/wuadmintools/s_wunetworkingtools/w95sockets2/default.asp
An x86 computer capable of running the supported operating systems well. This implies a CPU such
as an Intel 80386, 80486, a member of the Pentium family, or equivalent. A Pentium or better is
recommended.
At least 16 MBytes of random access memory (RAM). We recommend 32 Mbytes of RAM.
A hard disk with at least 7 MBytes of space available.
A CD-ROM drive on the computer where you are installing the Application Scanner.
A Web browser. Because the Application Scanner help is in HTML, you need a Web browser to view
the online version of the help. We recommend version 4.x of either Netscape
Navigator/Communicator or Microsoft Internet Explorer.
To install the Application Scanner, the login user on the computer where you are installing the program
must have Administrator privileges on Windows NT. (This does not apply to Windows 95/98).
Installing the Application Scanner

Follow these steps to install the Application Scanner program:
1.
Put the Application Scanner CD-ROM in the CD-ROM drive.
2.
Enter the following at a command prompt:

[drive]:setup.exe
where [drive] is the letter of your CD-ROM drive

3.
On the first dialog shown after Setup has loaded itself, press the Next button. The License
Agreement dialog is shown.
4.
Review the License Agreement. If you accept the terms of the agreement, press the Yes button.
5.
If you previously installed the Application Scanner, the Previous Version Detected dialog is shown.
To remove the previous version, select the Remove Application Scanner option and press the Next
button. The previous version is uninstalled. If the previous version was not completely removed, a
message is shown asking if you want to restart. You must restart for the installation to be successful.
After you restart the computer, you must begin the installation again, as described in Step 2.
6.
The Select Destination Directory dialog is shown. Select the directory where you want to install the
Application Scanner program. You must install the Application Scanner on a local hard disk of the
computer youre using. You should not install the program on a network drive. The default directory
is \Ganymede\AppScanner.
7.
Press the Next button and the Start Copying Files dialog is shown.
8.
Review the installation settings you have selected. To change your settings, press the Back button.
To accept the settings and continue with installation, press the Next button.
9.
The Application Scanner installation installs all the program files for the Application Scanner.
After installing the files, the installation program creates an Application Scanner folder. Inside of that
folder are four icons: Application Scanner, Application Scanner Readme, Application Scanner Help
and Script Editor. To start the Script Editor, click on the Script Editor icon. To start the Application
Scanner, click on the Application Scanner icon.
During the installation, a new .DLL file is installed in the TCP/IP protocol stack. See How Application
Scanner Works in the Working with the Application Scanner section on page 9 for information on how
the Application Scanner uses this .DLL to generate scripts.
All applications using the WinSock interface may experience a slight performance decrease (less than 5%)
while the Application Scanner is installed on the computer. This decrease will occur even when the
Application Scanner is not running. After you have finished using the Application Scanner, you should
uninstall the Application Scanner from the computer. See Removing the Application Scanner
(Uninstall) on page 7 in the Installing Application Scanner chapter for more information.
If the application you want to trace was running while you installed the Application Scanner, you
must exit the application and then restart the application. Otherwise, you will not be able to
successfully trace the application.
If you are planning to install or remove an adapter or protocol from your system, you should first
uninstall the Application Scanner. When the adapter is installed, the existing protocols are reordered
and the Application Scanner .DLL is not reordered by the adapters installation program. Thus, the
Application Scanner will not run. You must reinstall the Application Scanner.
Actions during the Application Scanner Installation

Heres what happens during the installation. Lets say you install the Application Scanner into the default
directory named \Ganymede\AppScanner. The Application Scanner installation creates directories
with the following structure.
Ganymede\AppScanner\
Executable programs and .DLL files
README.TXT file
Ganymede\AppScanner\Help
contains the help files used by the console
Ganymede\AppScanner\Scripts
default directory for saving Application Scanner scripts
Ganymede\AppScanner\Temp
contains temporary .HTM files generated when help is launched
Ganymede\AppScanner\Traces
Default directory for saving Application Scanner traces
Removing the Application Scanner (Uninstall)

After you have finished using the Application Scanner, you should remove the program from the
computer. Because the Application Scanner installs a .DLL in the TCP/IP stack, you may notice a slightly
slower performance in all WinSock applications on the computer until you uninstall the Application
Scanner. See How Application Scanner Works in the Working with the Application Scanner section on
page 9 for information.
To uninstall the Application Scanner, do the following steps:
1.
From the Windows Start menu, select the Settings submenu and the Control Panel menu item.
2.
Select the Add/Remove Programs icon. The Add/Remove Programs Properties dialog is shown.
3.
From the list, select Ganymede Software Application Scanner and then press the Add/Remove
button. The Uninstall wizard begins.
4.
After the Application Scanner is removed, the Add/Remove Programs Properties dialog is shown. To
exit the dialog, press the OK button.
5.
Reboot the computer.

Use Application Scanner if the library of predefined scripts doesn't contain a match for the transaction you
want to emulate. For example, if you want to emulate the impact on your network of an internallydeveloped
accounting product, use Application Scanner to generate the script. Application Scanner eliminates the need
to understand the scripting language.
How Application Scanner Works

We need to define a couple of terms before getting into Application Scanner Operation. Application Scanner
traces either applications or an individual process within an application. Applications are usually made up of
multiple processes. A transaction is a single complete action performed by you when you are using the
application. For example, opening an email is a single transaction where opening email and responding to it is
more than one transaction. We recommend that you trace individual transactions and create scripts for them.
Where possible we suggest that you trace specific processes rather than selecting the whole application. This
will reduce the chance that your trace is capturing information from other transactions that the application may
be performing while your specific transaction is also being traced.
Application Scanner guides you through the steps to select an application to trace. You can then start the trace
and perform the transaction. Application Scanner goes through a two-part process to generate a script based
on a transaction. First, it traces all the WinSock calls. Second, it attempts to generate a script from the trace
information.
1.
Traces the transaction

Application Scanner captures the WinSock calls made when the application runs. Application Scanner
records the WinSock calls in a trace file, which you must name when you save it. The default file
extension for the trace file is .AST.
While Application Scanner is installed, all WinSock application calls go through the new Layered Service
Provider (LSP) .DLL. The LSP is installed during Application Scanner installation. If there are
applications that you want to trace, restart them after installing Application Scanner. You will only need
to do this the first time Application Scanner is installed, not each time you restart it.
10
The following diagram illustrates how the LSP interacts with your computer:
If you trace an application supported by Application Scanner, a trace file is always created. This file
contains a record of all of the API calls performed during the trace. Applications that do not make
WinSock calls cannot be traced. If you trace an application that is not supported by Application Scanner,
the transaction you performed is not traceable and you will see an error message.
2.
Generates streams
After the trace is stopped, Application Scanner separates the WinSock API calls into streams. A stream
represents a set of calls to a specific destination address and destination port for each connection. If two
connections are active at the same time to the same destination address and destination port, they are
represented as two separate streams. Each stream can be saved as a script. After a script is generated, you
can use the Script Editor to view the script and make modifications to the script. After saving the script,
you can use this script in any Ganymede Software product that supports version 2.2 scripts. Application
Scanner creates scripts that can be used in Chariot 2.2 (or later) and in Pegasus 1.2 (or later).
Changes you make to the script through the Script Editor are not reflected in the trace information. The
trace information is captured by Application Scanner during the trace of the WinSock API calls and is not
changed in the generation or modification of scripts from the trace.
Before Creating a Script

You should do several things before starting Application Scanner.
Restart the application you want to trace.

If the application you want to trace was running when you installed Application Scanner program, you
must exit the application and restart it. When you install Application Scanner, an LSP is installed
11
between the application level and the WinSock level. Application Scanner can only trace WinSock calls
that go through the LSP. If the application was running before the LSP was installed, the WinSock calls
cannot go through the LSP until you close and restart the application. Once Application Scanner is
installed, you do not need to restart applications again if you restart Application Scanner later.
Determine the specific transaction you want to trace.

Be sure you are tracing a specific transaction, not an entire application or series of transactions. A
transaction is a task performed in a specific application, such as sending a file or checking e-mail. During
a trace, you should perform a single specific transaction within an application, instead of performing all
transactions within an application. For example, instead of creating one script that contains three
transactions, Logon, transactions within the application, and Logoffyou might want to create separate
scripts for each of these transactions. A script that emulates Logon would be useful for measuring the
strain on your network when everyone logs on in the morning, while a script that emulates a transaction
within the application can be used to emulate normal operating levels.
Familiarize yourself with the application and the transaction that you want to emulate with a script.
Application Scanner traces all WinSock calls made by the application or process between the time you
start the trace and the time you stop the trace. If you are unsure of the process to trace, you can try the
transaction. Next look at the Choose an active application or process dialog and press the Refresh button
and check the times of when the last WinSock API call was made. The process or application with the
most recent WinSock calls is probably the one you want to trace.
Again, be sure that you include only the specific actions that represent the transaction you are trying to
capture.
Special Cases When Tracing Datagram Packets

Some applications bypass the WinSock API. The following change will make some applications that use
datagram packet transfers use the WinSock API rather than bypassing it, therefore allowing Application
Scanner to trace the API calls. If you are unsuccessful in tracing the application, you can try this approach.
We have found that most applications that use datagram packets are traced by Application Scanner without the
need for this workaround.
Ordinarily, for datagram packet transfers, the RPC transport DLL bypasses the sendto and recvfrom
functions provided in WinSock 2 API, and communicates directly with the underlying device driver. This
improves the speed of packet transfers but makes WinSock Proxy features unavailable to the application.
Effective with Windows NT 4 Service Pack 2, the RPC transport checks the registry to see whether to use the
function calls provided in WinSock 2 API, or to speak directly with the device driver. To use RPC with
WinSock Proxy, edit the system registry on each machine to add the following entry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc
UseWinsockForIP: REG_DWORD "1"
Selecting the Application

To start Application Scanner, go to the Start Menu, select Programs, select Ganymede Software Application
Scanner, and then select the Application Scanner icon from the Start menu. Application Scanner begins.
The Trace an active Application dialog is shown and the Main Window is shown behind it. The dialog guides
you through the initial steps required to create a script based on an application transaction.
12
Your first decision is to choose whether you want to trace an application that is already running or one that is
not yet running. Selecting to trace an application that is not already running lets you trace program start up in
addition to other transactions. If you select to trace an application that is currently not running there are
dialogs that allow you to select the application either directly or by browsing your computer.
The Trace an Active Application dialog contains four buttons:
The Back button returns you to the previous dialog. Press this button to change your selections on a
previous dialog. This button is not available on the first window of the dialog.
The Next button takes you to the next dialog. Press this button after you have made your selection on the
current dialog and are ready to go to the next dialog.
The Cancel button closes the Application Selection dialog. The Main Window is then shown. Press this
button to exit the Selection dialog or to clear all selections.
The Help button shows the section in the online help that describes that dialog.
From the Start Menu, you can also launch the Script Editor, the Application Scanner Readme file and the
Application Scanner Help. The Script Editor can be used to view and edit the generated scripts to modify them
from what was captured during Application Scanner tracing. The Application Scanner Readme file contains a
quick summary of installation instructions, known limitations and operational guidelines for Application
Scanner. The Application Scanner Help is the context sensitive Help for Application Scanner, the Script
Editor and Messages Reference. The Help files contain an Index and all the Application Scanner
documentation contained in the printed book.
After installing the files, the installation program creates an Application Scanner folder. Inside of that folder
are three icons: Application Scanner, Application Scanner Readme, and Script Editor. To start the Script
Editor, click on the Script Editor icon. To start the Application Scanner, click on the Application Scanner
icon.
Script Optimization
Scripts are reduced in size when they are too big to be loaded by Chariot or Pegasus. This optimization step is
rarely needed; the following discussion is provided for technical completeness.
To generate scripts that are usable in Chariot and Pegasus some optimization techniques may be used. In most
cases, if you are taking a trace of a single transaction no optimization techniques will need to be applied. If
you are capturing trace information for a number of transactions, or for the same transaction many times,
Application Scanner may need to apply some optimization techniques to reduce the size of the generated script
from the trace information.
By default, Application Scanner automatically combines consecutive SEND or RECEIVE commands to
decrease the size of the script in cases where it does not change the integrity of the script. If a transaction
contains consecutive Send API calls all the same size, the commands are automatically combined when the
script is generated. For example, if the application you are tracing has four Send API calls, each with 200
bytes of data, Application Scanner combines these commands into one SEND command that sends 200 bytes of
data 4 times. The SEND command generated by Application Scanner is SEND 800,200. If the application
generates a Receive call of zero bytes, Application Scanner will not use it in creating a script.
If the last Send call in a series of consecutive Sends is smaller than the other Sends, the calls are automatically
combined when the script is generated. For example, the application you are tracing has three Send API calls.
The first two calls send 200 bytes and the third call sends 100 bytes. Application Scanner shortens the script
13
by combining these commands into one SEND command. The SEND command generated by Application
Scanner is SEND 500,200. This means that the buffer size of 200 is sent until 500 bytes are sent. The first
two Sends contain 200 bytes. Because 400 bytes have already been sent and the maximum number of bytes for
the command is 500, the third Send contains 100 bytes. If the network protocol is TCP, the next step is to take
the data size for Send or Receive calls, average them regardless of size and create a single command. For
example, if the stream contained three Sends of 300, 200 and 400 bytes, Application Scanner would combine
these into SEND 900, 300.
If after this level of combining consecutive Send and Receive calls the script is still too large to be used by
Chariot and Pegasus, Application Scanner continues to combine SEND and RECEIVE pairs to reduce the size
of the script. With this release of Application Scanner we have introduced an optimization method based on
grouping data sizes into buckets and taking an average of the data sizes within these buckets and then
combining the commands as described earlier. Application Scanner first takes data sizes inside each of these
buckets, averaging the sizes for Sends and Receives that fall inside the buckets and combine the commands. If
the script is still too large to be used in Chariot and Pegasus, Application Scanner combines buckets that are
one bucket away, and then two away and so on until the script has 1300 commands or less. Application
Scanner stops combining commands as soon as the script will fit and returns information to you about the level
of optimization that was required in a pop up message window. Here is an example of optimizing Send and
Receive pairs. Assume that the trace captured a series of WinSock calls of Send 10, Receive 5, Send 11,
Receive 8, Send 12, and Receive 8. Application Scanner would apply optimization techniques and generate a
script of LOOP 3, SEND 11, RECEIVE 7, ENDLOOP. Application Scanner took the Send and RECEIVE
sizes that were in the same bucket, averaged them and then put them in a Loop to reduce the number of
commands. The total amount of data sent and received and the order of the commands still are the same but
the data sizes for specific commands are slightly different.
The levels of optimization are:
Optimization Level 1
combines Send and Receive calls from the same bucket in the original trace
combines Send and Receive calls from one bucket away from those in the original trace
combines Send and Receive calls from two buckets away from those in the original trace
combines Send and Receive calls from three buckets away from those in the original trace
combines Send and Receive calls from four buckets away from those in the original trace
combines Send and Receive calls from five buckets away from those in the original trace
combines Send and Receive calls from six buckets away from those in the original trace
As the level of combining data sizes increases across buckets, the resulting script looks less like the real
applicationalthough the number and order of commands and the data throughput remain the same. There
may be some specific tests where you want to use as exact a representation of the application as possible and
the level of combining required is too large. In this case, you should limit the trace to less time or fewer
transactions.
14
The buckets are:
0-31 bytes
32-63 bytes
64-127 bytes
128-255 bytes
256-536 bytes
537-1,023 bytes
1,024-1,460 bytes
1,461-2,047 bytes
2,048-4,434 bytes
4,435-8,192 bytes
8,193- 17,884 bytes
17,885 bytes or more.
Understanding Streams
There are important distinctions among streams, connections, and applications. Application Scanner traces
application calls that go through Microsofts WinSock API. Application Scanner looks at each series of
commands that use the same destination port and creates a stream. If an application sends information to
different destination ports or to the same destination port at the same time, Application Scanner creates
different streams for each series of commands. Applications work differently in how many streams they create.
If you trace Web browser usage, there are usually multiple streams created; a browser gets multiple GIF files on
a Web page concurrently. Sending e-mail usually involves one stream.
After stopping a trace, Application Scanner identifies each stream with one of the following three terms:
Connect
The computer being traced initiated this TCP connection.
Accept
The computer being traced was the target for the incoming TCP connection, that is, its application issued
an Accept call to WinSock.
Stream
The pair of computers was exchanging UDP datagrams, or tracing was started in the middle of a
connection. The computer issuing the Connect or Accept call could not be clearly identified.
Application Scanner creates scripts for a single stream at a time. If the application traced creates multiple
streams you should select the stream that represents the largest percentage of the traffic or commands
generated by the application as the stream that best represents that application. You will notice that any DNS
or Internet Explorer Notify streams that may be created are grayed out. This is because they are not really part
of the traffic generated by the transaction that you traced. The DNS entries are created by the Domain Name
Server address resolution and these will occur naturally when you use the script in Chariot or Pegasus based on
the network configuration. The Internet Explorer Notify stream is a set of one-byte messages that Internet
Explorer sends to itself. These messages are internal to Internet Explorer and do not cross your network. All
other Internet Explorer activity is captured in the Application Scanner trace information.
Be sure that you captured the trace to the computer that you intended. Application Scanner returns the dotted
IP address of the responding computer. If the DNS server reassigns that IP address to another computer, you
may not be running to the correct computer. The hostname of the target computer can sometimes be the
confirmation you need to be sure you captured the right trace. You can get the host name from a dotted IP
address by entering the command:
15
ping a <ip address>
at a Windows command prompt. The dotted IP address should resolve and return the hostname along with the
results of the ping. You should run this command immediately after the trace has completed before the DNS
server reassigns the IP address to another host. To the degree that there are a large number of streams, or the
streams are all relatively the same size, then the resulting script will look less like the real application.
Main Window
The Main Window of Application Scanner lets you perform the following tasks:
Start a trace for which you have already selected the options
Stop a trace that is currently running
Start the Select Application dialog
Edit a script generated by Application Scanner
Save a script generated by Application Scanner
Change user settings
Open a trace
Save a trace
The Main Window contains four menus:
File menu
Trace menu
Options menu
Help menu
The lower portion of the window shows information about the trace. The Application Name is the application
that you have selected to trace. The Sends and Receives columns show the number of Sends and Receives.
Bytes Sent, and Bytes Received columns show the amount of data that was transferred for each stream during
the trace. The Port Number column shows the destination port used by calls from which the script was
generated. The Port Name column shows the name of the port used in the stream. For example, http is the
name for port 80 in Web browser traffic. The Protocol column shows the protocol used for the trace, which is
either TCP or UDP. The Destination Address is the network address of the computer that responded to the
commands sent by the computer being traced. The Connection Count is the number of connections observed
during the trace for a specific stream.
File menu
Application Scanner only creates scripts for specific streams so you must select a stream in order to save or edit
a script. To view the script that has been created or make changes to the script, select the Edit Script menu
item. You can also press the Edit icon. To save the script select the Save Script menu item. You can also
press the Save icon. The Save a Script dialog is shown. Select the directory in which you want to save the
script and enter the filename for the script.
You can open a previously saved trace by selecting Open Trace from the File Menu. The Open a Trace dialog
is shown. Select the directory in which previously saved traces are stored the trace and enter the filename for
the trace. To save the trace you can select Save Trace from the File Menu. The Save a Trace dialog is shown.
Select the directory in which you want to save the trace and enter the filename for the trace.
To exit Application Scanner, select the Exit menu item. Application Scanner is closed.
16
Trace menu
To restart the Application Selection dialog you can press Select Application from the Trace menu or press the
Select Application icon. To start a trace, select the Start Trace menu item or press the Start icon. Tracing
starts immediately when Start Trace is pressed from the Application Selection dialog. After you select the
menu item or the icon, go to the application to be traced and perform the transaction you want to trace. After
you have completed the transaction, select the Stop Trace menu item. You can also press the Stop icon.
Options menu
Changing User Settings
There are three tabs on the Change User Settings dialog.
The first tab is Tracing. The settings here let you change the default directory where traces are stored and to
limit the size of trace files created. You can change the default directory for traces if you want a file name that
you would recognize more easily or you have a place that you store traces of other types. The default file size
limit is 1 MB, which should be large enough for almost all traces of single transactions. You may want to keep
this file size low as a warning to be sure that you are tracing a single transaction. You can raise the limit if the
trace you are gathering is of an extremely complex transaction.
The second tab is Script. The settings here let you change the default directory where scripts are stored and to
save the port number that was found during the trace. You can change the default directory for scripts if you
want a file name that you would recognize more easily or you have a place that you store traces of other types,
perhaps for use in Chariot or Pegasus. You may want to keep the specific port as part of the script if there is a
firewall in the network between the computer being traced and the responding computer.
The third tab is Warnings. You can check the warning to detect Windows NT Service Pack 3. Application
Scanner works with Service Pack 3, however there are some limitations that are described in Known
Limitations on page 2 in the Introducing Application Scanner chapter.
Help menu
Select the Contents menu item to view help topics about Application Scanner.
Select the General Help menu item to get descriptive information about the window you are currently
viewing.
Select the Using Help menu item to get guidance on using the online help in Application Scanner.
Select the Keys Help menu item for a list of all keys and key combinations available in Application
Scanner.
Select the About Application Scanner menu item for details on Application Scanner version and build
level, and for information about service and support.
17
Keys Help for Application Scanner

You can use the following keys and key combinations in the Main Window.
F1
get help for Application Scanner
F2
get an index of all the available Application Scanner help topics
F11
get the About Application Scanner dialog, which shows your version and build level, and lets you get
product support information
Alt+F4
this key combination can be used to close any window or dialog box. When used to close a dialog box,
it has the same effect as pressing the Esc key or selecting Cancel with the mouse.
In addition to these keys, the Alt key can be used in combination with any underscored letter to invoke a menu
function. The menu function must be visible and not shown in gray. For example, pressing Alt+F shows the
File menu.
Tracing a Program: Active or Not Active

When you start Application Scanner, the Trace an active Program? dialog is shown. This dialog lets you select
if the program you want to trace is currently active or currently not active. An active program is one that is
running when Application Scanner is started and a program that is not active is one that is not running when
Application Scanner is started. You should select to trace a program that is not active if you want to trace the
startup of the program.
If the program you want to trace is currently active, select the active application or process option. If the
application you want to trace is currently not active, then select the program or process is currently not active
option.
To continue with the Application Selection, select the Next button. If you are tracing an application that is
currently active, the Choose an Active Application or Process dialog is shown. See Choosing an Active
Application or Process for more information. If you are tracing an application that is not active, the Specify
an Executable Filename dialog is shown. See Specifying an Executable Filename on page 18 in the Working
with Application Scanner chapter for more information.
Choosing an Active Application or Process

If you selected to trace a program that is currently active, the Choose an Active Application or Process dialog is
shown. This dialog lets you select the application or process that you want to trace from a list of currently
active programs.
Applications are the visible windows active on the computer while Processes are the currently running
executables. Since some executables start windows, there may be entries in both the Applications and
Processes lists that refer to the same entity.
Applications
To trace a transaction for an application that is currently active on the computer, select the Applications
option. The listbox shows the names for all currently open windows.
Processes
To trace a transaction in a background process that is currently active on the computer, select the
Processes option. An example of a Process is a service in Windows NT. The listbox shows the executable
files for all processes running on the computer. You can look at the column that shows the time of the last
WinSock call to help determine the process that you need to trace. Press the Refresh button to ensure that
18
you have the most recent time of a WinSock call. The column is refreshed automatically only when you
first start up the Application Selection dialog or switch between applications or processes to be traced.
When setting up a trace for a 16-bit application on Windows NT, the title of the application is not shown on
the Choose an Active Application or Process dialog. All 16-bit applications are represented by the
NTVDM.EXE Process. To trace a 16-bit application, select the NTVDM.EXE Process on the Choose an
Active Application or Process dialog. To generate an accurate script, you should only have one 16-bit
application active when you begin a trace. As a reminder, Application Scanner does not trace 16-bit
applications on Windows 95/98.
Select the application or executable file for the transaction that you want to trace. To continue with the
Application Selection dialog, press the Next button. The Enter the Application Script Name dialog is shown.
Specifying an Executable Filename

If you selected to trace a program that is currently not active, the Specify an Executable Filename dialog is
shown. The Specify an Executable Filename dialog lets you enter or select the filename of the executable
program of an application or process that is not currently active. You may want to trace an executable that is
not currently active in order to collect a trace of the application startup. Remember, the trace will start as soon
as you press the Start button.
Enter the filename of the executable program, without its drive or path, which you want to trace.
If you do not know the filename, select the Browse button, search your directories and select the filename for
the application. To find the executable filename for a program started from the desktop, right-click on its
program icon with the mouse, and look at the Target field on the Shortcut tab.
To continue with the Application Selection dialog, press the Next button.
Completing the Trace

After you have completed the transaction, return to the Application Scanner Main Window. See the Main
Window on page 15 in the Working with Application Scanner chapter for more information. The Main
Window shows information about the sends and receives that occurred in the currently traced application.
Press the Stop icon. Application Scanner generates streams from the API calls. You can save scripts, save the
trace file, or rerun the transaction. If the transaction that you traced had too many commands for Application
Scanner to create a usable script, the program uses optimization techniques to combine commands until a
usable script is created. If these techniques are employed a warning dialog will show you the amount of
optimization that was required. See Script Optimization on page 12 in the Working with Application
Scanner chapter for more information. You may notice that the time on the trace differs from the time shown
on the Main Window to an earlier one when you press Stop. This is because Application Scanner uses the last
WinSock call time as the end time rather than the time that Stop is pressed. The last WinSock call is when the
transaction really ended rather than when the monitoring ended.
If you did not perform the transaction exactly as you want it to be recorded in the script, press the Start icon.
Application Scanner tracing is restarted and all of the trace options you previously selected are used. You can
now perform the transaction again and then press the Stop icon when you are done. Application Scanner
separates the API calls into streams and performs the script generation portion of the process.
To save the script, you must first select which stream you want to save, then select the Save Script menu item
from the File menu or press the Save icon. If you want to use the script in Chariot, save your scripts in the
19
same directory the other Chariot scripts are stored (the default location is Ganymede\Chariot\Scripts.) If
you want to use the script on another computer where Chariot is installed, save the script and then move the
script to the location of the Chariot scripts on the computer you want to use it. You can use the Script Editor to
modify the script. To access the Script Editor, select the Edit Script menu item from the File menu or launch
the stand alone Script Editor.
If you want to use the script in Pegasus 1.2 (or later), save the script in any directory on your computer or
network from which you can import into Pegasus. You can modify the script in the Script Editor. However,
before you can use a script created by Application Scanner or a predefined script modified in the Script Editor,
you must import the application scripts into Pegasus. See Importing Application Scripts in the Pegasus User
Guide for more information.
To get realistic test results when using a script generated by Application Scanner in either Pegasus or Chariot
you should do the following:
1.
Select Endpoint 1 as a computer in your network that represents the computer from which you generated
the trace.
2.
Select Endpoint 2 as the computer that represents the partner to Endpoint 1 in the traced transaction
scenario.
3.
Select the same communication protocol used during the trace: either TCP or UDP.
All WinSock calls that you trace are shown as the Endpoint 1 side of the script that is generated. Ideally, the
endpoints you choose should be ones that help you determine the impact of the script on your network.
Remember that if the application uses Accept commands, Application Scanner will change the script such that
the traced computer will be Endpoint 2 in the script rather than Endpoint 1 (which is the normal case for a
client computer).
20

The Script Editor lets you create new scripts as well as change the existing ones. You can tailor scripts to
emulate the flows of particularly complex applications.
The Script Editor is included with Chariot and can also be accessed as a standalone product if you have
purchased the Application Scanner.
If you want to use the Script Editor as a standalone product, you can run the Script Editor by selecting the
Script Editor icon in the Application Scanner Folder.
If you want to use the Script Editor from Chariot, you can access the Script Editor two ways.
If you want to edit a script and have the changes to the existing script used by all pairs, select the Edit
Scripts menu item from the Tools menu on the Main window. Also, select this menu item if you
want to create a new script and you want the script to be available to all pairs.
If you want make changes to an existing script and have the option of saving the changes with a
specific pair, highlight the pair in the Test window and select the Edit menu item. From the Edit an
Endpoint Pair dialog, press the Edit this script button. The Script Editor is shown. Note that you
can also save the changes to a file that can be used by other pairs if you access the Script Editor from
this dialog.
The main window of the Script Editor shows the commands for the script and a list of the scripts
variables.
In the top half of the window, Endpoint 1s portion of the script is shown on the left; Endpoint 2s on the
right. These are sequential lists of the commands (and their parameters) to be executed by the endpoints.
You can look at a long script by scrolling through it. You can access a dialog that lets you edit the
highlighted commands parameters one of three ways:
1.
highlight a command and double-click
2.
select the Edit parameter menu item from the Edit menu
3.
highlight a command and click the right mouse button and then select the Edit menu item
The lower half of the window summarizes the script variables. You can access a dialog that lets you edit
the highlighted variable one of three ways:
1.
double-click on the highlighted variable
2.
select the Edit variable menu item from the Edit menu
3.
click the right mouse button and then select the Edit menu item
Commands in the File menu let you handle script files and exit the editor. The Edit menu contains
commands that operate on the currently selected script commands or variables. To insert a command in a
script, select a command (or group of commands) in the top half of the window, and then choose the
command to be inserted from the Insert menu. The new command is inserted after (or around) the
selected command(s).
21
22
The Application Script Name field shows a brief (40 character) description of the script. This script
name is required; it is important for identifying the script in other Ganymede Software products. If you
are creating a new script, be sure to enter descriptive information.
The toolbar provides a shortcut to the most commonly used menu items. You can move variables up and
down in the list. The Swap icon lets you move the selected command to the other endpoint. Use the
Insert icons to insert commands into the script.
Editing a Parameter of a Script Command

Most script commands have parameters which you can tailor. To edit a parameter, select the parameter in
the top half of the Script Editor window and do one of the following:
1.
double-click on the parameter
2.
press the Enter key
3.
select the Edit Parameter menu item from the Edit menu
The Edit Parameter dialog is shown.

The Constant and Variable radio buttons let you define the type of parameter.
The Parameter field shows the parameter currently being edited. All of the parameters for the command
are available in the pulldown menu. If defined to be a variable, enter or select the name of the variable in
the Variable Name field. A list of appropriate variables previously defined in the script is available from
the pulldown menu. See Editing a Script Variable for more information on the variable fields.
Editing a Script Variable

Variables are used in scripts to let script command parameters be changed globally within a script.
Variables can be used to control LOOPs, define port numbers, specify the data type for a SEND, etc.
To edit a script variable, highlight the variable in the bottom half of the Script Editor window and do one
of the following:
1.
double-click on the parameter
2.
press the Enter key
3.
select the Edit variable command from the Edit menu
The Edit Variable dialog is shown.

The Variable name field must be unique within the script, and not contain blanks.
The Default value field lets you specify the initial value for the variable, when the script is loaded from
file into a test. The field accepts numbers to 999,999,999. On some variable types, such as the buffer size
on SEND and RECEIVE, you can use other values, such as the term DEFAULT or AUTO. The
DEFAULT value depends on the network protocol and the endpoints you are using. AUTO, when entered
for the port_number variable, specifies that Endpoint 1 should choose the port number.
The type of variable used for the SLEEP command allows five values: Constant Value, Uniform
Distribution, Normal, Poisson, and Exponential. For a Constant Value, one field is presented for the
value. For a distribution, two fields let you enter the upper and lower distribution range. All values are in
milliseconds. See the Application Scripts manual for more information on the distributions.
Enter a description of the variable in the Variable comment field.
The Variable help field provides details about this variable and how to use it in the script. You can
customize the help text by entering information in this field.
Press the Reset button to return the value in the Current value field to the value that was in the Default
value field the last time you exited the Edit Variable dialog for this variable.
The File Menu (Script Editor)

The File menu lets you work with scripts. You can open a script in the Script Editor in two ways:
1.
select the Open menu item
2.
press Ctrl+O
The Open a Script dialog is shown. Select the script that you want to open. The script is shown in the
Script Editor. You can then modify the script and save the script.
You can exit the Script Editor in two ways:
1.
go to the File menu select the Exit menu item
2.
press F3
If you have modified the current script and not saved your changes, a message box is shown asking if you
want to save your changes to the current script.
Adding a New Script

You can create a new script based on script templates. From within the Script Editor, select the New
menu item from the File menu. The New Script dialog is shown. Select one of the following script
templates:
Basic Long Connection
This template is a version of the Credit Check transaction that uses a long connection. This is a
quick transaction that emulates a series of credit approvals. A record is sent from Endpoint 1.
Endpoint 2 receives the record and sends back a confirmation. Use this template as a starting point
for most scripts or if you are unsure of which template to use.
Basic Short Connection
This template is a version of the Credit Check transaction that uses short connections. This is a quick
transaction that emulates a series of credit approvals. A record is sent from Endpoint 1. Endpoint 2
receives the record and sends back a confirmation. Use this template to create a script that initiates a
connection for each transaction.
Empty
This template contains the minimum parameters required in script. The script template does not
contain any SEND or RECEIVE commands. Use this template as a starting point to create a script
from scratch.
23
24
Streaming
This template contains the commands necessary for a streaming script. Because the script contains
all of the commands required for the purposes of a streaming script, you can not modify the structure
of the script. However, you can modify the variables in the script. Use this template for streaming
scripts.
Press the OK button. The Script Editor shows the script template you selected.
Enter a brief description (up to 40 characters) of the script in the Application Script Name field. This
script name is required; it a very important field in future versions of Ganymede Software productsbe
sure to enter descriptive information.
When editing script parameters, you can change their names and the variables included in the parameter.
See Editing a Parameter of a Script Command for more information.
When editing script variables, you can change their names, their current and default values, and their
comments. See Editing a Script Variable for more information on editing variables.
For a full description of the script commands and their parameters and the rules for governing the creation
of valid scripts, see the Messages and Application Scripts manual.
To save the script, select the Save menu item from the Tools menu.
Saving a Script
Saving Scripts from the Standalone Script Editor
If you are using the Script Editor as a standalone product and want to save your changes with the same
script file name, select the Save menu item from the File menu. If you have not previously saved this
script, the Save Script File As dialog is shown.
If you want to save your changes under a new file name, select the Save As menu item from the File
menu. The Save Script File As dialog is shown. Enter or select the filename.
Saving Scripts from within Chariot

If you access the Script Editor from within Chariot, you can save your modifications to a script on two
different levels: Pair Level and Script Level. If you save a script at the pair level, the modifications to the
script or the new script is only available to the pair from which you accessed the Script Editor. If you save
a script at the file level, the modifications or the new script is available to all pairs.
You can only save your changes at the pair level if you access the Script Editor from the Edit a Pair
dialog. If you access the Script Editor from the Tools menu, you can only save your changes at the file
level.
Pair Level
The Script Editor lets you modify a script and have those modifications only used by the pair the
script was attached to when it was modified. The modifications are not reflected in the version of the
script attached to other pairs.
You can save your modifications on the Pair level in two ways:
1.
go to the File menu and select the Save to pair menu item
2.
press Ctrl+S
The Script Editor saves the modifications to the pair level. Note that the file name shown in the
title bar does not change. If you are saving a new script, Untitled is shown in the title bar.
File Level
The Script Editor lets you modify a script and have those modifications available to new pairs created
after you modified the script. If you previously associated the script with a pair, your modifications
will not be reflected in the version of the script associated with the pair. To have the modifications
reflected in existing pairs, you must reattach the script to the pair.
If you access the Script Editor from the Edit a Pair dialog and want to save a script at the file level,
select the Save As menu item from the File menu. Enter or select the filename you want to save the
script as and press the OK button. The Script Editor saves the modifications to the script on the file
level. The filename of the script is shown in the title bar.
If you access the Script Editor from the Tools menu and want to save your changes with the same
script file name, select the Save menu item from the File menu.
If you access the Script Editor from the Tools menu and want to save your changes under a new file
name, select the Save As menu item from the File menu. The Save Script File As dialog is shown.
Enter or select the filename.
The Edit Menu (Script Editor)

The menu items on the Script Editor Edit menu let you work with the script shown in the Script Editor.
Undo
You can undo an unlimited number of previous actions in the Script Editor. This menu item is only
available when your last action was "not selecting the Undo menu item." You can undo previous actions
in two ways:
1.
go to the Edit menu select the Undo menu item
2.
press Ctrl+Z
Redo
You can reverse your last undo and return the script to the state before you selected the Undo menu item.
This menu item is only available when your last action was an Undo.
You can redo actions in two ways:
1.
go to the Edit menu and select the Redo menu item
2.
press Ctrl+E
Delete
You can delete commands and variables from a script. First, highlight the command or variable you want
to delete by clicking on the command or variable. Once selected, you can delete the command or variable
in two ways:
25
26
1.
go to the Edit menu and select the Delete menu item
2.
press the Delete key
The command or variable is deleted from the script and is not shown in the Script Editor.
Move Up
You can move variables up in the sequence of commands in a script. To keep the script valid, the Move
Up menu item and Move Up icon are only available when moving the highlighted variable up is a valid
move. In some cases, using the Move Up function may cause the highlighted variable to move up to the
next valid place in the script or may cause other variable to move.
First, select the variable that you want to move up by clicking on the variable. Once selected, you can
move the variable up in three ways:
1.
go to the Edit menu and select the Move up menu item
2.
press Ctrl+Up
3.
press the Move up icon
Move Down
You can move variable down in the sequence of commands in a script. To keep the script valid, the Move
Down menu item and Move Down icon are only available when moving the highlighted variable down is
a valid move. In some cases, using the Move Down function may cause the highlighted variable to move
down to the next valid place in the script or may cause other variables to move.
First, select the variable that you want to move down by clicking on the variable. Once selected, you can
move commands up in a script in three ways:
1.
go to the Edit menu and select the Move down menu item
2.
press Ctrl+Up
3.
press the Move down icon
Swap Sides
You can move a command to the opposite endpoint or switch a command pair. For example, if you
highlight SEND/RECEIVE and use the swap functionality, the command pair is now RECEIVE/SEND.
This functionality is only available for certain commands.
First, select the command that you want to move to the other endpoint by clicking on the command. Once
selected, you can swap sides in three ways:
1.
go to the Edit menu and select the Swap sides menu item
2.
press Ctrl+W
3.
press the Swap sides icon
Edit Parameter
You can change a commands parameters and assign the command as either a constant or a variable. See
Editing a Script Variable for more information on editing parameters.
First, select the command that you want to edit by clicking on the command or a parameter for the
command. You can edit parameters in three ways:
1.
go to the Edit menu and select the Edit parameter menu item
2.
double-click with your mouse
3.
press the Enter key
The Edit Parameter dialog is shown.
Edit Variable
You can change a variables name, description, value, and default value. See Editing a Script Variable
for more information on editing variables.
First, choose the variable that you want to edit by clicking on the variable. You can edit the variable in
three ways:
1.
go to the Edit menu and select the Edit variable menu item
2.
double-click with your mouse
3.
press the Enter key
The Edit Variable dialog is shown.
27
28
The Insert Menu (Script Editor)

The Insert menu lets you insert the following commands into the script:
Script Command
Description
CONNECT
Creates a connection. Also inserts a DISCONNECT command.
SEND from Endpoint 1
Sends a buffer of the size and type you specified from Endpoint 1 and receives
data at Endpoint 2.
SEND from Endpoint 2
Sends a buffer of the size and type you specified from Endpoint 2 and receives
data at Endpoint 1.
FLUSH at Endpoint 1
Directs the Endpoint 1 protocol stack to flush its buffers of unsent messages.
FLUSH at Endpoint 2
Directs the Endpoint 2 protocol stack to flush its buffers of unsent messages.
CONFIRM from Endpoint 1
Requests an acknowledgment from Endpoint 2 that the previously-sent data has

been received.
CONFIRM from Endpoint 2
Requests an acknowledgment from Endpoint 1 that the previously-sent data has

been received.
SLEEP at Endpoint 1
Simulates a user or processing delay at Endpoint 1.
SLEEP at Endpoint 2
Simulates a user or processing delay at Endpoint 2.
LOOP
Repeats the commands between LOOP and END_LOOP.
Highlight the location in the script where you want to insert the command or the Group of Commands to
insert around. From the Insert menu, select the command you want to insert in the script.
All scripts must adhere to specific rules. See the Messages and Application Scripts manual for more
information. Only the commands that can be inserted at the selected location in the script are available.
Script Editor Keys Help

You can use the following keys and key combinations as shortcuts in the Script Editor window, instead of
using the mouse.
Del
delete the highlighted variable from the script.
Enter
edit the currently-highlighted parameter on a command, or script variable (depending on whether the
focus is in the top or bottom portion).
F1
get help for the Script Editor window.
F2
get an index of all the available help topics.
F3
exit the window.
F9
show the keys and key combinations available in a window.
F10
get information about how to use operating system help.
F11
get the About dialog, which shows your version and build level, and lets you get product support
information.
Ctrl+E
redo the last operation to the scriptassuming youve just chosen Undo.
Ctrl+N
set up a new script. The New Script dialog is shown. You can add a new script based on five
templates.
Ctrl+O
open an existing script file.
Ctrl+S
save a script file, using the filespec shown on the titlebar. If the script is still untitled, the Save
Script File As dialog lets you choose a path and filename for the script.
Ctrl+W
swap the sides for the currently-highlighted script commands. That is, move the Endpoint 1
command to Endpoint 2, and move the Endpoint 2 command to Endpoint 1.
Ctrl+Z
undo the last operation.
Ctrl+
Down
Arrow
move the currently-highlighted script variable one row lower in the list of variables. You cannot
move the port_number variable from the bottom of the list.
Ctrl+Up
Arrow
move the currently-highlighted script variable one row higher in the list of variables. You cannot
move the port_number variable from the bottom of the list.
Alt+F4
this key combination can be used to close any window or dialog. When used to close a dialog, it has
the same effect as pressing the Esc key or pressing Cancel with the mouse.
In addition to these keys, you can use the Alt key in combination with any underscored letter to invoke a
menu function. The menu function must be visible and not shown in gray. For example, pressing Alt+F
shows the File menu.
29
30
Troubleshooting
31
Troubleshooting
If the Application Scanner fails to generate a script during the trace, you will receive an error message. The
error message shows the name and location of the TRACE.AST file. You can then e-mail this file to Ganymede
Software Customer Care. See Ganymede Software Customer Care for information on contacting Ganymede
Software. The Customer Care team can use this file to help you create a script or diagnose the problem.
Viewing the Error Log

If the Application Scanner encounters a problem, it logs the problem information into an error log file. The
error log file is named TRACE.LOG and is written to the directory where the Application Scanner is installed.
You can use the FMTLOG program to read from the binary log file and write the formatted output to stdout.
The FMTLOG program is installed in the same directory as the Application Scanner.
Here is the syntax of the FMTLOG command to be entered at a command line:
FMTLOG log_filename >output_file
Reading Error Messages

Application Scanner messages are reported with the Error Message dialog. Youll recognize it by its stop sign
icon in the upper left-hand corner.
The dialog shows the primary error message. Heres an example of a primary error message:
No script was generated. The application you were tracing did not make
any WinSock calls, or the application was not restarted after
Application Scanner was installed.
Press the Message help button at the bottom of this dialog. This provides an explanation, likely causes for the
error, and information about how to resolve the error. Sometimes there is secondary error information shown
in this dialog, to provide further isolation for the problem.
The Show details button gives advanced technical information about the problem. For example, it shows the
return code number for failed communication calls.
32
Common Problems
Here are some possible problems you may encounter while running the Application Scanner.
The Application You Were Tracing Did Not Make Any WinSock Calls
An Application Cannot Run After the Application Scanner is Installed
The Application You Were Tracing Did Not Make Any WinSock Calls
If the application you are tracing does not make WinSock calls during the transaction, you will receive the
message No script was generated. The application you were tracing did not make any WinSock calls.
You received this message because the Application Scanner can only create scripts based on WinSock calls and
your transaction did not contain any of these calls. You will need to trace a transaction that contains a
WinSock call. For example, Microsoft Exchange cannot be traced on Windows NT because it bypasses
WinSock.
You will also receive this message if the application you were tracing was running when the Application
Scanner was installed and you did not restart the application before starting the trace. To generate a script, you
should restart the application and then restart the trace.
An Application Cannot Run After the Application Scanner is Installed

If you are running Windows NT Service Pack 3 and an application that uses WinSock calls (such as the IIS
Server) doesnt run correctly after you have installed the Application Scanner, the application may use the
WinSock calls ReadFile and WriteFile. Applications using these WinSock calls will not run correctly
with the Application Scanner and Windows NT Service Pack 3 installed.
To correct this problem, download and install Windows NT Service Pack 4 (or later) on the computer where
you are running the Application Scanner. You can download the service pack from
http://www.microsoft.com/support/winnt/default.htm. You will then be able to run the other application.
If you do not want to install Windows NT Service Pack 4 (or later) on the computer, uninstall the Application
Scanner. You will then be able to run the other application.
33

We like hearing from our customers, no matter what their concerns. We provide both Customer Service and
Technical Support.
Customer Service
For any Ganymede Software product, call Customer Service for:
Upgrade orders
Registration problems
Product information
Referrals to dealers and consultants
Replacement of missing or defective parts (disks, manuals, etc.)
Information about technical support services
For questions about how to use our software, see the Troubleshooting Guidelines section below. In addition,
we keep the Ganymede Software Web site up-to-date with the latest information on all aspects of our products:
http://www.ganymede.com/
If necessary, you can contact us at:
Morrisville, NC 27560-9119
888-GANYMEDE (888-426-9633) toll free in the USA
919-469-0997 (voice)
919-469-5553 (fax)
e-mail: info@ganymede.com
Troubleshooting Guidelines
Our customer care team is always happy to assist you with any problems you encounter. We recommend you
try the following steps before calling for assistance, as you can usually locate efficient solutions for many
common problems in the existing documentation:
1.
Check the Technical Support Web site. Our technical support Web site provides:
Frequently-asked questions (and answers)
Links to the latest fixes and third-party software updates
34
Downloads of the latest documentation including product user guides and specification sheets
Tuning tips
Application Script Library To reach the technical support Web site, point your browser to
http://www.ganymede.com/support/
2.
Review the Troubleshooting chapter in your products User Guide. This chapter provides solutions to
many common problems as well as information about viewing the error logs and getting the latest product
updates and fixes.
3.
Review the README file. This file contains updated information that does not appear in this version of
the manual. Its a good idea to print this file and keep a copy nearby.
How to Get Technical Support

If you are still unable to resolve your problem, or if you suspect youve found a bug, contact the Ganymede
Software customer care team for technical support.
Registered users can reach our customer care team at:
888-GANYMEDE (888-426-9633) toll free in the USA
919-469-0997 (voice) (select option #6)
919-469-5553 (fax)
e-mail: support@ganymede.com
You can send us questions by fax or e-mail any time.
We think the best way to contact us directly is by e-mail, because it gives us an easy way to exchange files.
Telephone support is available Monday through Friday, from 9:00am to 6:00pm Eastern Time.
Index
Index
A
Accept, 14
Application Name, 15
Application Scanner
WinSock, 32
application script name, 22
applications, 17, 18
B
Bucket Sizes, 14
Bytes Received, 15
Bytes Sent, 15
F
File menu, 15
FMTLOG, 31
G
Ganymede Software
Customer Care, 33
H
Hardware/Software Requirements, 5
help, 2
Help menu, 16
C
Change User Settings, 16
Choose an Active Application or Process dialog, 17
choose an inactive application or process, 18
completing the trace, 18
Connect, 14
Connection Count, 15
constant value, 22
creating scripts, 11
D
Data Bucket Sizes, 14
Destination Address, 15
distribution, 22
DNS, 14
documentation
online help, 2
E
edit
script command parameters, 22
script variables, 22
scripts, 21
editing scripts, 15, 18
e-mail address, 33
error log, 31
exiting Application Scanner, 15, 18
exiting the Script Editor, 23
I
IE Notify, 14
installation, 5
K
keys help, 17
Script Editor, 29
known limitations
Application Scanner, 2
L
limitations, 2
lower distribution, 22
M
Main Window, 15, 18
messages, 31
N
new script, 23
O
online help, 2
optimization levels, 13
35
36
Optimizing script size, 12

Options menu, 16
P
Port Name, 15
Port Number, 15
processes, 17, 18
product overview, 1
Protocol, 15
R
random sleep, 22
Readme file
before calling Technical Support, 34
Receives, 15
S
saving
script, 24
saving scripts, 15, 18
Script Editor
adding a new script, 23
edit
parameters, 22
edit menu, 25
editing variables, 22
exiting, 23
file menu, 23
insert menu, 28
inserting script commands, 28
opening a script, 23
overview, 21
saving, 24
Script Optimization, 12
selecting an application, 11
Sends, 15
shortcut keys, 17
Script Editor, 29
SLEEP, 22
Specify an Executable Filename dialog, 18
starting a trace, 16
stopping a trace, 16, 18
Stream, 14
streams, 14
T
Technical support, 34
Trace an Active Program dialog, 17
Trace menu, 16
TRACE.LOG, 31
transactions, 9
U
understanding streams, 14
uninstall, 7
upper distribution, 22
W
Whats New in Application Scanner 1.2, 1
WinSock, 2, 32
working with Application Scanner, 9

Www.ganymede.com

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Www.ganymede.com

Загружено:

Авторское право:

Доступные форматы

Ganymede: Welcome to Ganymede Software!

Welcome to Ganymede Software!

http://www.ganymede.com/ (1 of 2) [3/14/2000 8:15:32 AM]

Copyright 2000 Ganymede Software Inc. -- Privacy Statement

Ganymede: Welcome to Ganymede Software!

http://www.ganymede.com/ (2 of 2) [3/14/2000 8:15:32 AM]

Ganymede: Search Ganymede

http://www.ganymede.com/search.cgi [3/14/2000 8:15:37 AM]

Ganymede: Site Map

The Leader in Network Performance Management Solutions

Career Opportunities at Ganymede

Welcome to our Newsletter!

The Performance Monitor Archive

The Industry Standard for Measuring Performance

http://www.ganymede.com/sitemap.phtml (1 of 4) [3/14/2000 8:15:40 AM]

How Does Chariot Work?

Chariot can give you peace of mind!

Chariot Technical Specifications

Test Labs Using Chariot

Ganymede: Site Map

Try Chariot for Free!

Monitoring and Troubleshooting Application Performance

How Does Pegasus Work?

Pegasus Summary of Features

Pegasus Technical Specifications

Nervous About Enterprise Performance?

What is causing your application performance problems?

Pegasus Development Partners

The Performance Endpoint... A workhorse you can count on!

Performance Endpoints and Chariot

Performance Endpoints and Qcheck

Performance Endpoints and Pegasus

Performance Endpoint and the Cobalt RaQ

Operating System and Protocol Support

Download Performance Endpoints

Creating Custom Application Scripts

Ganymede Software Download Registration Form

Application Scanner Technical specifications

Dedicated to Ongoing Support

Chariot Technical Support

http://www.ganymede.com/sitemap.phtml (2 of 4) [3/14/2000 8:15:40 AM]

Chariot Service Updates

Ganymede: Site Map

Chariot Third Party Updates

Chariot Tools and Utilities

Chariot Testing Tips

Pegasus Technical Support

Pegasus Service Updates

Pegasus Third Party Updates

Endpoint Technical Support

Endpoint Service Updates

Endpoint Third Party Updates

Application Scanner Technical Support

Application Scanner FAQ

Application Scanner Documentation

Application Scripts Techncial Support

Application Script Library

Application Script FAQ

Application Script Documentation

Technical Support Download Center

Ganymede Software Education

http://www.ganymede.com/sitemap.phtml (3 of 4) [3/14/2000 8:15:40 AM]

Ganymede Software Training Overview

Ganymede: Site Map