performance endpoints -...

Performance Endpoints

IBM MVS March 31, 2002

Contents i

THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE

SUBJECT TO THE TERMS OF A LICENSE AGREEMENT OR A NON-DISCLOSURE AGREEMENT. EXCEPT AS

EXPRESSLY SET FORTH IN SUCH LICENSE AGREEMENT OR NON-DISCLOSURE AGREEMENT, NETIQ CORPORATION PROVIDES THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE

IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SOME STATES DO NOT

ALLOW DISCLAIMERS OF EXPRESS OR IMPLIED WARRANTIES IN CERTAIN TRANSACTIONS; THEREFORE, THIS

STATEMENT MAY NOT APPLY TO YOU.

This document and the software described in this document may not be lent, sold, or given away without the prior written permission of NetIQ Corporation, except as otherwise permitted by law. Except as expressly set forth in such license agreement or non-disclosure agreement, no part of this document or the software described in this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or otherwise, without the prior written consent of NetIQ Corporation. Some companies, names, and data in this document are used for illustration purposes and may not represent real companies, individuals, or data.

This document could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein. These changes may be incorporated in new editions of this document. NetIQ Corporation may make improvements in or changes to the software described in this document at any time.

© 1995-2002 NetIQ Corporation, all rights reserved.

U.S. Government Restricted Rights: The software and the documentation are commercial computer software and documentation developed at private expense. Use, duplication, or disclosure by the Government is subject to the terms of the NetIQ standard commercial license for the software, and where applicable, the restrictions set forth in the Rights in Technical Data and Computer Software clauses and any successor rules or regulations.

ActiveAgent, ActiveEngine, ActiveKnowledge, ADcheck, AD Modeler, AppAnalyzer, Application Scanner, AppManager, the AppManager logo, Chariot, Directory and Resource Administrator, Domain Migration Administrator, End2End, Enterprise Administrator, Event Manager, Exchange Administrator, Exchange Migrator, File Administrator, File and Storage Administrator, Ganymede, Ganymede Software, the Ganymede logo, Knowledge Pack, Knowledge Scripts, Migration Assessor, Mission Critical Software, the Mission Critical Software logo, MP3check, NetIQ, the NetIQ logo, NetIQ Partner Network, the NetIQ Partner Network logo, NetWare Migrator, OnePoint, the OnePoint logo, Operations Manager, OU Populator, Pegasus, Qcheck, Security Manager, Server Consolidator, WebTrends, Work Smarter, and XMP Module are trademarks or registered trademarks of NetIQ Corporation or its subsidiaries in the United States and other jurisdictions. All other company and product names mentioned are used only for identification purposes and may be trademarks or registered trademarks of their respective companies.

ii IBM MVS Endpoint

Contents

About This Book and the Library ...................................................................................... v

Chapter 1 IBM MVS 7 Installation Requirements for MVS Endpoints................................................................... 7 Endpoint Installation for MVS...........................................................................................10

Installation.............................................................................................................11 Installation Considerations for Multiple MVS Images..........................................15

What Happens During Installation ...................................................................................18 Removing the Endpoint Package (Uninstall).......................................................19

Configuring MVS Endpoints..............................................................................................19 MVS Configuration for APPC................................................................................20 MVS Configuration for TCP/IP .............................................................................23 APPC Performance with MVS/VTAM ...................................................................29 Some Guidelines for Tuning APPC Performance for MVS/VTAM ......................32

Running MVS Endpoints ...................................................................................................33 Starting an MVS Endpoint.....................................................................................33 User-Defined CMP Files........................................................................................35 Changing the Endpoint's Priority .........................................................................36 How to Tell If an MVS Endpoint Is Active ..........................................................36 Disabling Automatic Startup .................................................................................36 Storage Handling and Pre-Allocation (with VTAM 4.4) ......................................37 Stopping an MVS Endpoint ..................................................................................37

Logging and Messages ......................................................................................................38 Getting the Latest PTFs and Service Updates...................................................................41

Updates for IBM MVS ...........................................................................................41 Updates for Computer Associates ........................................................................42

Chapter 2 Performance Endpoints 43 Endpoint Requirements and Capabilities .........................................................................43

Operating System and Protocol Stack Support....................................................43 Endpoint Capabilities ........................................................................................................47

Performance Endpoint Support for Chariot Functions........................................48 Performance Endpoint Support for End2End Functions .....................................50 Endpoint Computer Resource Guidelines ...........................................................52 Endpoint Versions.................................................................................................54

Chapter 3 Endpoint Initialization File 55

ALLOW ..................................................................................................................56

Contents iii

SECURITY_AUDITING......................................................................................... 57 AUDIT_FILENAME ............................................................................................... 57 ENABLE_PROTOCOL........................................................................................... 58 SAFESTORE_DIRECTORY.................................................................................... 58 UPDATE_SERVER................................................................................................. 59 END2END_SERVER .............................................................................................. 59

Customizing endpoint.ini for Windows Endpoints ......................................................... 59 Configuring Endpoints for Large-Scale Customization ....................................... 60

Index 63

iv IBM MVS Endpoint

About This Book and the Library

This brief guide provides conceptual information about the free Performance Endpoint software NetIQ Corporation provides in association with its Network Performance Management products, and covers installation and configuration for one specific endpoint platform. For information about installing and configuring all the endpoint platforms, including HP-UX, IBM AIX, IBM MVS, Linux, Microsoft Windows 95, Windows 98, Windows Me, Windows NT, and Windows 2000, Windows XP, Novell NetWare, Sun Solaris, Compaq Tru64 UNIX, FreeBSD UNIX, IBM OS/2, Linux IA-64, Microsoft Windows 3.1, Windows XP (64-bit), SCO UnixWare, SGI IRIX, and Spirent TeraMetrics, is available in the HTML-formatted Performance Endpoints Guide in your product’s Help system, or you can download other individual endpoint guides in .PDF format from the World Wide Web at http://www.netiq.com/support/pe/pe.asp.

Intended Audience This book provides information about Performance Endpoint software for users of NetIQ End2End, Chariot, and Qcheck.

Other Information in the Library The library provides the following information resources:

User Guides for Chariot and End2End Provide general information about each product and guide you through installation and use.

Messages and Application Scripts Guide Describes the application scripts included with End2End and Chariot and provides a detailed reference to the error messages for all NetIQ Network Testing and Monitoring products.

NetIQ Products NetIQ Corporation provides integrated products that simplify and unify directory, security, operations, and network performance management in your extended enterprise. These products also help organizations prepare for and migrate to Windows 2000. NetIQ Corporation provides the following categories of products:

Administration The NetIQ Administration products provide tools for setting and enforcing policies that govern user accounts, groups, resources, services, events, files, and folders. These products automate time-consuming administration tasks and allow you to delegate many of these tasks.

About This Book and the Library v

http://www.netiq.com/support/pe/pe.asp

Analysis The NetIQ Analysis products enable you to evaluate your complex environment and its various components. These products allow you to analyze your Web site traffic and performance, as well as manage your visitor relationships.

Migration The NetIQ Migration products provide tools for preparing for and migrating to Windows platforms. These tools also help you reorganize your environment and consolidate resources as needed.

Monitoring The NetIQ Monitoring products provide control and automation for monitoring your enterprise performance and service availability. These products also include extensive network monitoring capabilities to provide a complete, end-to-end management solution for e-business infrastructures.

Security The NetIQ Security products enable you to secure your extended enterprise and identify potential weaknesses. These products allow you to administer, assess, enforce, and protect all aspects of security in your enterprise from a central portal.

Testing The NetIQ Testing products enable you to pinpoint existing network problems and resolve those problems quickly and effectively. You can also simulate network activity and identify potential issues before you implement new software packages in your production environment.

Contacting NetIQ Corporation Please contact us with your questions and comments. We look forward to hearing from you. For support around the world, please contact your local partner. For a complete list of our partners, please see our Web site. If you cannot contact your partner, please contact our Technical Support team.

Telephone: 919-469-0997 888-426-9633 (only in the United States and Canada)

FAX: 919-469-5553

Email: [email protected]

Support: [email protected]

Web Site: www.netiq.com

vi IBM MVS Endpoint

mailto:[email protected]

mailto:[email protected]

http://www.netiq.com/

Chapter 1 IBM MVS

This chapter explains the installation, configuration, and operation of the Performance Endpoint software for IBM’s MVS operating system.

MVS was renamed OS/390 a few years ago. When we refer to MVS, we mean to include versions of OS/390, as well.

Installation Requirements for MVS Endpoints Here are the hardware and operating system requirements for running the endpoint program with MVS:

• A computer capable of running MVS well. IBM’s P/390 system is sufficient to run a few connection pairs. However, to run a large number of connections, a System/390 (30xx, 43xx, or ES9000) is required.

• A version of IBM MVS that supports the APPC and/or TCP/IP network protocol software you plan to use (these are discussed in the following table). We recommend MVS/ESA SP V4R2.2 or later.

• At least 3.0 MBytes of available DASD space.

• At least 2.8 MBytes of virtual storage in an available address space. We recommend that you run the endpoint on MVS such that it acquires the memory it needs dynamically. Thus, you would set REGION=0M in the endpoint JCL. The total requirement depends on the virtual storage usage of the underlying protocol stack and the number of concurrent connection pairs. For very large tests involving hundreds of connections through a single endpoint, additional memory may be required.

• The SAS/C version 7.00 C Run-time Library. This version is supplied with the MVS endpoint.

You also need compatible network protocol software:

About This Book and the Library 7

for APPC Our software uses VTAM’s APPCCMD macroinstruction interface. VTAM-supported LU 6.2 application programs are those whose APPL definition statement includes APPC=YES. The IBM MVS endpoint supports any level of MVS compatible with the VTAM APPCCMD API. APPCCMD has been available since at least ACF/VTAM for MVS/ESA V3R4.2.

VTAM began supporting APPN in version 4 release 1 (V4R1); APPN makes the configuration of links and sessions much easier than without it. In addition, IBM began shipping the APPC Application Suite with VTAM V4R2. We recommend having its APING application set up, and testing your configuration before installing the MVS endpoint.

for RTP, TCP, and UDP The MVS endpoint operates using TCP/IP protocol stacks from IBM and Computer Associates. (Computer Associates acquired Sterling Software, which had previously acquired Interlink Computer Sciences, the original developer of the TCPAccess product).

The endpoint supports IBM V3R1 and IBM V3R2 (OS/390 V1R3) TCP/IP for MVS. We recommend TCP/IP V3R2 or later -- IBM rewrote its TCP/IP protocol stack for V3R2 to improve performance significantly. The endpoint makes calls to the IUCV Sockets programming interface for RTP, TCP, and UDP. OS/390 version 2.6 and higher (with TCP/IP stack version 3.5) includes support for IP Multicast testing with Chariot.

The following table documents the evolution of IBM TCP/IP naming conventions:

8 IBM MVS Endpoint

External Name TCP/IP Version Release Date Supported by the IBM MVS Endpoint?

SecureWay Communications Server for OS/390 V2R9 IP

IP V3R8 GA March 2000 Yes

SecureWay Communications Server for OS/390 V2R8 IP

IP V3R8 GA Sept. 1999 Yes

eNetwork Communications Server for OS/390 V2R7 IP





TCP/IP V3R4 or Stage 2 IP V2R5

GA March 1998 Yes

OS/390 TCP/IP OpenEdition for MVS/ESA and OS/390 R3 and R4

TCP/IP V3R3 or Stage 1

GA June 1997 Yes

OpenEdition MVS Applications feature

OE apps feature GA Sept. 1996 Yes

IBM TCP/IP V3R2 for MVS TCP/IP V3R2 GA Sept. 1996 Yes

The endpoint supports the NetworkIT:TCPaccess version 4.1 and 5.2 stack from Computer Associates. The endpoint makes calls to the TLI Sockets programming interface for RTP, TCP, and UDP.

We recommend that you configure your networking software -- and making sure that it is working correctly -- before installing the endpoint. We also recommend that you get up-to-date with the latest MVS service levels. “Getting the Latest PTFs and Service Updates” on page 41 discusses a variety of ways to get the latest fixes.

SAS/C Run-Time Library The MVS endpoint is shipped with the SAS/C Version 7.00 C run-time library and requires this version for correct operation.

If you have installed this or a later release of the SAS/C run-time library to the link pack area (LPA), comment out or remove the following STEPLIB statement in your NETIQ.ENDPOINT.JCL(ENDPOINT) member:

//* DD DSN=NETIQ.ENDPOINT.LINKLIB,DISP=SHR


Changes in IBM MVS Software IBM has changed the packaging of their MVS software from individual products to a suite of products packaged together under the brand of Communications Server for OS/390 Version X Release Y, for example OS/390 Version 2 Release 5. We have tested with IBM’s packaged software and have found significant improvements in the TCP/IP performance. VTAM version 4.4 is the last VTAM release that was packaged separately. Much of IBM’s work in VTAM v4.4 is a performance rewrite. IBM extensively reworked the APIs and storage management for performance. See the Web site www-4.ibm.com/software/network/commserver/library/whitepapers/white_vtam44perf.html for information on IBM’s performance improvements in VTAM v4.4.

IBM’s APING program is an internal application in VTAM version 4.4. That means that the program 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 as real applications.

Endpoint Installation for MVS The endpoint runs as an application on MVS, and thus is configured like other applications. It uses APPC and/or TCP/IP; the underlying APPC and/or TCP/IP software must therefore be installed and properly configured on MVS. If this is the first time that you have installed the endpoint on IBM OS/390 Version 2 Release 5 or later releases, you will need to define an OMVS Security Segment in RACF (or equivalent product) for the user ID associated with the endpoint job. Refer to Chapter 5 in the IP Planning and Migration Guide (IBM publication number SC31-8512) in the IBM OS/390 documentation under “OS/390 UNIX Security Considerations” under the subheading “Requirement for an OMVS Segment.” This contains the detailed requirements and instructions for setting up this segment.

First, decide the names of the data sets where the endpoint will reside on MVS. That is, choose the volume serial (VOLSER), the TSO user ID (USERID) to own the application, the high-level qualifier (HLQ), and the second-level qualifier (SLQ), and determine the path to your local “file send” or “file upload” program (for example, via a 3270 emulator or FTP). We recommend the following assignments:

HLQ=NETIQ

SLQ=ENDPOINT

For example, we recommend a data set named NETIQ.ENDPOINT.xxxxxxxx, where “xxxxxxxx” names a specific endpoint data set. Make sure that the TSO user ID has the authority needed to create the data sets and install the application. You may need to schedule installation time with the MVS Systems Administrator or Security Administrator.

10 IBM MVS Endpoint

http://www-4.ibm.com/software/network/commserver/library/whitepapers/white_vtam44perf.html



Most of the installation steps are performed from a PC running Windows that has a TSO session to MVS.

You will supply the VOLSER, USERID, HLQ, and SLQ to the installation program on the PC, as well as the location of your program for file uploading. The installation program builds the necessary JCL files on the PC, and then uploads them to MVS. Make sure you enter the installation parameters in uppercase characters.

There are two ways that you can install the MVS Performance Endpoint:

• via FTP

• via the SEND command (also referred to as IND$FILE)

The MVS endpoint is installed from a PC connected to your MVS system. As part of the install, files are uploaded to MVS. This can be done using either ftp or the SEND command (also known as IND$FILE). If you plan to use the SEND command and are running version 3.2 or 3.4 of the IBM TCPIP stack on your MVS system, you will need to have your MVS systems programmer install the fix for APAR P017039.

The steps for installation are as follows:

1. If you have an MVSTEMP directory left from your old installation of the MVS Endpoint, you should erase it, both the contents and the directory itself. This is to ensure that these old files do not interfere with the new installation. If you erase only the contents, you may get a SEVERE error message saying that the return code for the MVS install could not be checked and that the installation did not complete successfully. You can ignore this message and proceed with the installation.

2. Run the setup program from the CD-ROM or diskettes at your local PC connected to MVS. It asks for the parameters it needs (HLQ, SLQ, VOLSER, etc.) to build the JCL. With this information, it also builds other files, which will be uploaded to MVS. The following topics explain how to install the endpoint from a CD-ROM and from the World Wide Web, as well as how to replace an existing MVS endpoint.

Installation The endpoint installation goes through the following steps:

1. Creating the JCL

2. Copying the common files

3. Copying the endpoint files

4. Copying the pre-defined data compression files (Cmpfiles).

If TCP/IP and FTP are installed on MVS, we recommend that you use FTP to install the endpoint. If you will be using the endpoint on a system without TCP/IP, skip to “SEND Command or IND$FILE Installation” on page 12.


FTP Installation In a DOS command window, change the directory to the location used for the MVS temporary files (the default is MVSTEMP). In that directory, run the batch file “ftpload.bat” with the following parameters:

ftpload <host.domain.com> <uid> <hlq> <slq> <volser>

Here’s a breakdown of what to enter for each parameter:

• <host.domain.com> is the hostname or IP address of your MVS system.

• <uid> is a valid TSO userid with privileges to allocate files.

• <hlq> is the high-level qualifier for endpoint files.

• <slq> is the second-level qualifier.

• <volser> is the volume serial of the destination pack.

For <hlq>, <slq> and <volser>, you must use the same values you specified in the dialogs of the install script. By default, the <hlq> value is NETIQ and the <slq> value is ENDPOINT.

When the batch file is finished, run the resulting FTP script with the following command:

ftp < MVSUP.FTP

When prompted for “password,” enter the password for the TSO user ID.

This batch file will allocate the JCL and CMP libraries, upload the data and programs, and submit the RECEIVE job to decompress the loadlib and linklib. Once you have verified that RECEIVE completed successfully, the sequential files NETIQ.ENDPOINT.SEQLOAD and NETIQ.ENDPOINT.SEQLINK are no longer needed and may be deleted.

This completes the installation of the MVS endpoint.

SEND Command or IND$FILE Installation Allocate the data sets on MVS to receive the uploaded JCL and CMP partitioned data sets, as well as the MVSBUILD and ECHRMSG data sets.

For this example, we’ll use NETIQ as the <hlq> and ENDPOINT as the <slq>. Thus we will allocate the following data sets:

• NETIQ.ENDPOINT.JCL

• NETIQ.ENDPOINT.CMP

• NETIQ.ENDPOINT.MVSBUILD

• NETIQ.ENDPOINT.ECHRMSG

The term NETIQ.ENDPOINT must be in capital letters for the endpoint to operate successfully after the install.

12 IBM MVS Endpoint

1. To create the JCL partitioned data set, do the following:

from ISPF:

− select Utilities (option 3); − select Data Set (option 2); − enter a Data Set Name to allocate, then enter “A” on the command line; − fill in the Allocate New Data Set panel, as shown in the following

example:

Data Set Name . . . : NETIQ.ENDPOINT.JCL Volume serial . . . .

NETIQ (Blank for authorized default volume) * Generic unit. . .

. . (Generic group name or unit address) * Space units . . . .

. CYLINDER (BLKS, TRKS, CYLS, KB, MB or BYTES) Primary

quantity. . . 1 (In above units) Secondary quantity. . 1 (In

above units) Directory blocks. . . 4 (Zero for sequential data

set) Record format . . . . FB Record length . . . . 80 Block

size . . . . . 6160 Expiration date . . .

2. To create the CMP partitioned data set, do the following:

from ISPF:


example:

Data Set Name . . . : NETIQ.ENDPOINT.CMP Volume serial . . . .

NETIQ (Blank for authorized default volume) * Generic unit. . .

. . (Generic group name or unit address) * Space units . . . .

. TRKS (BLKS, TRKS, CYLS, KB, MB or BYTES) Primary quantity. .

. 100 (In above units) Secondary quantity. . 25 (In above

units) Directory blocks. . . 4 (Zero for sequential data set)

Record format . . . . U Record length . . . . 0 Block size . .

. . . 32760 Expiration date . . .

3. To create the MVSBUILD data set, do the following:

from ISPF:


example:


Data Set Name . . . : NETIQ.ENDPOINT.MVSBUILD Volume serial . .

. . NETIQ (Blank for authorized default volume) * Generic unit.

. . . . (Generic group name or unit address) * Space units . .

. . . BLKS (BLKS, TRKS, CYLS, KB, MB or BYTES) Primary



set) Record format . . . . FBS Record length . . . . 1 Block


4. To create the ECHRMSG data set, do the following:

from ISPF:


example:

Data Set Name . . . : NETIQ.ENDPOINT.ECHRMSG Volume serial . .

. . NETIQ (Blank for authorized default volume) * Generic unit.

. . . . (Generic group name or unit address) * Space units . .

. . . BLKS (BLKS, TRKS, CYLS, KB, MB or BYTES) Primary



set) Record format . . . . FBS Record length . . . . 1 Block


5. Leave the TSO session at the READY prompt. From the PC directory you specified in the installation (the default location is c:\mvstemp), run the UPLOAD.BAT file. This batch file can be run from DOS, Windows, or OS/2; it executes your emulator’s SEND command to upload files to MVS.

If the emulator SEND command is in your PATH, just issue the command as follows:

UPLOAD

If the emulator SEND command is not in your PATH, you must specify the PATH, which must end with a backslash (\). Some examples follow:

UPLOAD C:\EPCLIENT\

UPLOAD “C:\Personal Communications\”

Make sure that all the files transferred successfully.

6. Go back to your TSO session. In ISPF, edit the data set that you set up to receive the JCL. In our example, NETIQ.ENDPOINT.JCL is the name of that data set.

7. Submit the RECEIVE job contained in this data set. This loads the LOADLIB and LINKLIB data sets from a sequential format to a partitioned data set (PDS). It also allocates three log data sets. The log data sets are named as follows:

14 IBM MVS Endpoint

− NETIQ.ENDPOINT.LOG − NETIQ.ENDPOINT.AUDIT − NETIQ.ENDPOINT.ASSERT

Next, the sequential file named NETIQ.ENDPOINT.SEQLOAD is unloaded to a new PDS named NETIQ.ENDPOINT.LOADLIB. Then the sequential file named NETIQ.ENDPOINT.SEQLINK is unloaded to a new PDS named NETIQ.ENDPOINT.LINKLIB.

To submit the job from IPSF:

− enter “SUB” next to the RECEIVE job. − Check for successful completion of the submitted job in the JES Output

Queue, using SDSF.

After the RECEIVE job has successfully completed, the sequential files NETIQ.ENDPOINT.SEQLOAD and NETIQ.ENDPOINT.SEQLINK are no longer needed and may be deleted.

This completes the installation of the MVS endpoint.

Installation Considerations for Multiple MVS Images The PC-based endpoint installation dialog box helps you install the MVS endpoint on a single MVS system. Multiple copies of the endpoint cannot be run on the same MVS image. However, a copy of the MVS endpoint can be run on each MVS image in a shared environment. This type of environment requires special considerations when installing.

The following items need to be unique for each copy of the endpoint you intend to run. Instructions associated with each item follow the table.


Endpoint JCL HLQ.SLQ.ENDPOINT(JCL) A separate execution JCL is needed for each copy of the endpoint being run, to allow for image-specific DD names and parameters.

Endpoint Assert file Endpoint Audit file Endpoint Log file

In the PC install dialog, by the HLQ and SLQ parameters.

These files are allocated by the RECEIVE job.

End2End (Pegasus) Safestore files

In ENDPTINI, in the SAFESTORE_DIRECTORY statement, originally set by the HLQ and SLQ parameters specified in the PC install dialog.

Files are dynamically created when the endpoint is used for End2End active monitoring. These “safestore” files sort the schedule, script, and queued up results to send back to the End2End server.

VTAM switched major node definition

In the VTAMLST switched major node definition (see sample member ENDPTSW)

This is only needed if using APPC. The switched major node definition needs to be defined to VTAM on each MVS image running a copy of the endpoint.

APPC LU names In the APPLID= parameter of the ENDPOINT JCL, and also in the VTAMLST application definitions (see sample member ENDPTAP)

This is only needed if using APPC. Application LU names must be unique within a given VTAM network. The names supplied in the sample member can be change, so long as the APPLID= parm of the JCL matches.

TCP/IP stack In the TCP= parameter of the ENDPOINT JCL.

Each MVS image will have its own TPC/IP stack.

Endpoint JCL HLQ.SLQ.ENDPOINT(JCL) A separate execution JCL will be needed for each copy of the endpoint being run, to allow for image-specific DD names and parameters.

Endpoint JCL: Take the following actions:

• Copy the ENDPOINT member for each copy desired.

• In each copy of the ENDPOINT JCL, customize the following:

− //ENDPTLOG

− //ENDPTAUD

− //ASSERT

− //SYSTCPD

− //ENDPTINI

− APPLID= parameter

16 IBM MVS Endpoint

− TCP= parameter

Endpoint Assert file; Endpoint Audit file; Endpoint Log file: Take the following actions:

• In the installation dialog box, use the HLQ and SLQ parameters to specify the first system-specific set of files. Note that the HLQ and SLQ parameters are not limited to a single level of qualification; thus you could specify ENDPOINT.MVS1 for the SLQ value.

• For the subsequent system-specific files, submit an IEFBR14 job, using the allocation specifications for these files used in the RECEIVE JCL.

End2End (Pegasus) Safestore files: Take the following actions:

• You will need to have a unique copy of ENDPTINI for each endpoint image.

• Be sure that the endpoint JCL points to the appropriate ENDPTINI member via the //ENDPTINI DD statement.

• Edit the SAFESTORE_DIRECTORY statement to specify a unique level of qualification for this copy of the endpoint.

VTAM switched major node definition: Using the ENDPTSW sample as a model, define the VTAM switched major node in the appropriate VTAMLST for each MVS system where you will be running a copy of the endpoint.

APPC LU names: Take the following actions:

• Using the ENDPTAP sample as a model, define the VTAM APPLIDs to the respective VTAMLST for each copy of the endpoint you will be running.

• Modify the ENDPOINT JCL for each system such that the APPLID= parameter names the appropriate application definitions for the specific system.

TCP/IP stack: Set this value in each copy of the ENDPOINT JCL on each system to the appropriate value. See “TCP (for use with TCP and UDP)” on page 29 for more information.

Notes • You cannot use system symbols (similar to what is available in members of

SYS1.PARMLIB).

• A single copy of the LOADLIB and LINKLIB used in the //STEPLIB may be shared by all the executing instances of the endpoint.

• The MVSBUILD data set, as well as the CMP data sets and the ECHRMSG data set may also be shared by all executing instances of the endpoint.

• If multiple MVS images running the endpoint utilize the same operator console you may find it beneficial to use the WTOR=0 parameter, which disables the outstanding WTOR message used to facilitate control of the endpoint.


What Happens During Installation Here’s what happens during the installation steps. Let’s say you installed the MVS endpoint into the data sets named NETIQ.ENDPOINT.xxxxxxxx. They contain the following:

• The JCL members the endpoint uses

• The message members the endpoint uses

• The README member

• Member ENDPTINI of the JCL data set. This member corresponds to the file named endpoint.ini on other operating systems. See “Endpoint Initialization File” on page 55 for information about tailoring this file for individual endpoints.

• A partitioned data set containing the data compression files. These members contain data of different types, such as typical text or binary data. The endpoint uses the member data sets as data on SEND commands. The different data types can be used to vary the data compression performance of your network hardware and software. On MVS, these data sets have the following names (where “HLQ” and “SLQ” are the high-level and second-level qualifiers you entered during installation):

//BIB DD DISP=SHR,DSN=HLQ.SLQ.CMP(BIB)

//BOOK1 DD DISP=SHR,DSN=HLQ.SLQ.CMP(BOOK1)

//BOOK2 DD DISP=SHR,DSN=HLQ.SLQ.CMP(BOOK2)

//GEO DD DISP=SHR,DSN=HLQ.SLQ.CMP(GEO)

//LENA DD DISP=SHR,DSN=HLQ.SLQ.CMP(LENA)

//NEWS DD DISP=SHR,DSN=HLQ.SLQ.CMP(NEWS)

//PAPER1 DD DISP=SHR,DSN=HLQ.SLQ.CMP(PAPER1)

//PAPER2 DD DISP=SHR,DSN=HLQ.SLQ.CMP(PAPER2)

//PIC DD DISP=SHR,DSN=HLQ.SLQ.CMP(PIC)

//PROGC DD DISP=SHR,DSN=HLQ.SLQ.CMP(PROGC)

//PROGL DD DISP=SHR,DSN=HLQ.SLQ.CMP(PROGL)

//PROGP DD DISP=SHR,DSN=HLQ.SLQ.CMP(PROGP)

//TRANS DD DISP=SHR,DSN=HLQ.SLQ.CMP(TRANS)

No system files or data sets are automatically modified by the installation of the MVS endpoint.

During the uninstall process, the MVS endpoint will be removed, with the exception of the NETIQ.ENDPOINT JCL and the safestore files that are created if you are running with NetIQ End2End. The safestore files must be removed manually; we strongly recommend that they not be deleted if you are planning to run the endpoint with End2End again. There are four file types of these safestore files.

• .ql, which is a directory of all the End2End servers that have been in contact with the endpoint;

• .qe files, which the test schedules distributed to the endpoint by the End2End server;

18 IBM MVS Endpoint

• .q00 and .q01 files, which are report queues that contain test results until they are sent back to the End2End server.

Should you have reason to install an older endpoint, you should delete any safestore files using the following steps:

1. Stop the endpoint.

2. Delete the safestore files from the endpoint directory (or from the data set specified by the SAFESTORE_DIRECTORY keyword in the ENDPTINI member of the JCL data set). Safestore files have an extension of .q*; you may delete them as you would any other data set on MVS.

3. Uninstall the current endpoint.

4. Install the desired endpoint.

Removing the Endpoint Package (Uninstall) If you need to remove the endpoint, you must first stop the endpoint program (if it is running). To remove the endpoint, you will need to first delete the following libraries:

NETIQ.ENDPOINT.ASSERT

NETIQ.ENDPOINT.LOG

NETIQ.ENDPOINT.AUDIT

NETIQ.ENDPOINT.ECHRMSG

NETIQ.ENDPOINT.MVSBUILD

Configuring MVS Endpoints The MVS endpoint program runs as a job or as a started task, using the network application programming interfaces, such as Sockets and APPC, for all of its communications. However, your communications software must be configured and running correctly. The following steps guide you through this verification.

1. Determine the network addresses of the computers to be used in tests (IP addresses or LU names).

2. Select a service quality (for APPC only).

3. Test the network connections.

4. Update the EXEC PGM values in your endpoint JCL.

The following topics describe how to accomplish these steps for MVS:

• “MVS Configuration for APPC”

• “MVS Configuration for TCP/IP” on page 23

• “Updating Endpoint JCL Values” on page 27


MVS Configuration for APPC This section provides selected information about configuring APPC. If you are new to configuring APPC, start with the guidance provided by the APPC network software you’re using. In addition, review the APPC/MVS configuration information in MPCONFIG guide.

IBM has created a thorough (but aging) “redbook” to assist in setting up APPC across a variety of platforms. This guide is called the MultiPlatform APPC Configuration Guide and can be viewed or downloaded from the Web. The URL is: www.redbooks.ibm.com/pubs/pdfs/redbooks/gg244485.pdf

APPC with MVS VTAM This section describes the steps for setting up APPC at the endpoint, for use with IBM’s VTAM software.

Decide what role the MVS endpoint will play in your testing: Endpoint 1, Endpoint 2, or both. When it’s Endpoint 1, you want to be sure that 1) you can reach it from the Chariot or Qcheck Console or the End2End server, and 2) you can get from MVS to Endpoint 2 using APPC. When it’s Endpoint 2, you obviously want to be able to reach it from Endpoint 1, using APPC. In either case, test the ability to get APPC sessions using APING -- this ensures that VTAM itself is configured correctly.

Some additional VTAM configuration may be required:

• Setting up “Switched Local Major Node” definitions, for the PUs at the other ends of the APPC sessions

• Setting up “APPL Segment” definitions, for use when testing with multiple LUs at the same MVS endpoint.

Testing the APPC Connection with APING When you have decided what LUs and modes you are using, you can run a quick test using a program named APING.

APING is a test application that is included with most APPC software packages. It is similar to Ping in TCP/IP; it is an echo program that sends a block of data to another computer. That computer receives the data and sends it back. APING verifies that APPC is correctly installed at a pair of computers, that they are connected to the network, and that it is possible to get an APPC session using the mode you have selected.

For MVS, APING is packaged with the APPC Application Suite, which has been available since VTAM V4R2.

From the partner computer, first run APING to VTAM using LU names and mode names already defined at VTAM. (In our software, the mode name is known as the “service quality.”) If APING works, it shows a table of timing information. This endpoint should be ready for APPC testing. Continue testing connections to the other endpoints you will use.

20 IBM MVS Endpoint

http://www.redbooks.ibm.com/pubs/pdfs/redbooks/gg244485.pdf

Although APING is packaged with VTAM and other APPC stacks, it is not automatically configured. If you run APING and get a CPI-C return code of CM_TP_NOT_AVAILABLE or CM_TP_NOT_RECOGNIZED, it means that APING is not configured on the other computer. The good news is that you did get a connection to the other computer, which means that our software should be able to use this endpoint for APPC testing.

If you get any other APPC return code, you have a configuration problem somewhere. You should correct this before starting to run our software.

Make sure that you can run APING successfully from the computer running the Chariot or Qcheck Console or the End2End server to each computer serving as Endpoint 1, and between each pair of endpoints involved in a test -- before starting your testing with APPC.

Determining the APPC Network Address (LU Name) A fully-qualified LU name is the easiest network address to use with our software. It is constructed by concatenating the network name, a period, and a control point (CP) or LU name. Although you can define multiple LUs at one computer, one always serves the role of the control point LU. This CP name is returned by the command you entered. A fully qualified LU name, such as NETA.ENDPTMVS, is constructed by appending the CP name to the network name. You will need to know the LU names of each endpoint you use for APPC testing.

Adding a Switched Local Major Node Definition to VTAM VTAM requires a Switched Local Major Node definition for each PU with which it will be connected.

We’ve shipped a sample of the needed JCL, named ENDPTSW. Make changes to ENDPTSW, then copy from the data set named NETIQ.ENDPOINT.JCL(ENDPTSW) into SYS1.VTAMLST.

You can activate the definitions in ENDPTSW manually by issuing the following at the VTAM command prompt:

V NET,ACT,ID=ENDPTSW

If you want VTAM to automatically start the Switched Major Node segment (ENDPTSW), add (ENDPTSW) to SYS1.VTAMLST(ATCCONxx).

Using Multiple ACB Names (LU Names) VTAM requires an APPL segment to be defined to use any APPC LUs with the MVS endpoint.

We’ve shipped a sample of the needed JCL, named ENDPTAP. Make changes to ENDPTAP, then copy from the data set named NETIQ.ENDPOINT.JCL(ENDPTAP) into SYS1.VTAMLST.

You can activate this APPL segment (ENDPTAP) manually by issuing the following at the VTAM command prompt:


V NET,ACT,ID=ENDPTAP

If you want VTAM to automatically start the APPL segment (ENDPTAP), add (ENDPTAP) to SYS1.VTAMLST(ATCCONxx).

The MVS endpoint can use from 1 to 8 LUs (ACBs) at a time. The LU names must match those defined to VTAM in the VTAM APPL segment. You specify the list of LUs that the endpoint can use in its JCL. If you plan to use just one LU, for example, ENDPTMVS, here’s how to specify its name on the APPLID parameter:

// PARM=‘APPLID=ENDPTMVS, ...’

Use parentheses and commas to specify multiple LUs. The length of the PARM line in the JCL cannot exceed 100 bytes. For example, here’s a specification with 4 LU names:

// PARM=‘APPLID=(ENDPTMVS,MYLU2,USIBMNR5,JOHNQ), ...’

Here’s how to specify 8 LUs, spanning multiple lines:

// PARM=‘APPLID=(ENDPTMVS,AJOEP001,AJOEP002,AJOEP003,

// AJOEP004,AJOEP005,AJOEP006,AJOEP007), ...’

Selecting a Service Quality (APPC Mode Name) Most networking protocols have some mechanism to allow applications to tell the network what kind of service it requires. APPC does this through the mode definition. Several modes come predefined on most APPC products. These include the following:

APPC Mode Name Description

#INTER Interactive data, high priority, no security

#INTERSC Interactive data, high priority, secure connections only

#BATCH Batch data, low priority, no security

#BATCHSC Batch data, low priority, secure connections only

For many tests, these modes are sufficient. However if you are trying to emulate a particular APPC application, you should select the same mode name that it uses.

You can create a new mode or modify an existing one. The method for doing this depends on whether you are running APPC in a VTAM subarea network, or in an APPN network. For a VTAM subarea network, the default table is called ISTVTCOS, and for APPN the default table is called COSAPPN.

For information on defining either of these tables, see the chapter on “User-Defined Tables and Data Filters,” under the section entitled “Class of Service” in the OS/390 SecureWay Server: SNA Resource Definition Reference (IBM publication number SC31-8565). Also, reference the section titled “APPN and Subarea Class of Service Resolution in OS/390 SecureWay Server: SNA Network Implementation Guide” (IBM publication number SC31-8563).

22 IBM MVS Endpoint

In order to change these definitions you will probably need the assistance of your network systems administrator or systems programmer.

APPC TP Name APPC applications use an LU name to decide which computer to connect to in a network. They use a TP name to decide which application program to connect to within a computer.

The endpoint uses the string GANYMEDE.CHARIOT.ENDPOINT as its TP name. This TP name is used when communicating with endpoints via an APPC connection.

MVS Configuration for TCP/IP The RTP, TCP, and UDP protocols use TCP/IP software for network communications. TCP/IP offers two forms of network addresses: IP addresses and domain names. An IP address is a 32-bit numeric address. It is represented in dotted notation as a set of four numbers separated by periods, such as 199.72.46.202. The alternative, domain names are in a format that is easier to recognize and remember, such as www.netiq.com. To use domain names, you need either a Domain Name Server (DNS) set up in your network or an /etc/hosts file on each computer.

To use NetworkIT:TCPaccess with the MVS endpoint, you must make the following change in your JCL to NETIQ.ENDPOINT.JCL(ENDPOINT) to run with TCPaccess version 4.1: Set the TCP proc symbolic parameter to the subsystem name chosen for TCPaccess. The default subsystem name is ACSS.

For example:

//ENDPOINT PROC SOUT=‘A’, CHOOSE A SYSOUT CLASS

// HLQ=NETIQ, DATA SET HIGH LEVEL QUAL.

// SLQ=ENDPOINT, DATA SET 2ND LEVEL QUAL.

// MAXRPLS=600, MAXIMUM # RPL BUFFERS TO ALLOCATE

// MAXCNOS=100, MAXIMUM # CNOS BUFFERS TO ALLOCATE

// TCP=ACSS, TCP/IP STACK ADDRESS SPACE NAME

// APPLID=(ENDPTMVS,ENDPT001) VTAM APPLICATIONS

//*

//ENDPOINT EXEC PGM=ENDPOINT,REGION=0M,TIME=1440,

//

PARM=‘APPLID=&APPLID,MAXRPLS=&MAXRPLS,MAXCNOS=&MAXCNOS,TCP=&TCP’

//STEPLIB DD DSN=&HLQ..&SLQ..LOADLIB,DISP=SHR

// DD DSN=TCPICS.V410.SAS6LOAD,DISP=SHR

// DD DSN=NETIQ.ENDPOINT.LINKLIB,DISP=SHR

Configuring for Common INET Running multiple TCP/IP stacks from different vendors on the same MVS image poses unique difficulties.


If you intend to run the endpoint with the default TCP/IP stack, you should not encounter any problems, assuming that the load libraries for the stack are in the linklist and/or lpa list. However, special customization is required if you plan to run the endpoint with a non-default stack, especially if that stack's load libraries are not in the linklist and/or lpa list, or if they are present in these concatenations, but occur after the other vendors’ libraries.

In such cases, you will need to modify the //STEPLIB concatenation in the ENDPOINT JCL to point to the appropriate load libraries for your TCP stack.

Determining Your IP Network Address You can find the MVS computer’s local IP address with the following steps. From within TSO, look in the TCP/IP profile data set for the HOME IP address of each link in the host:

1. From the SDSF Primary Option Menu, select DA (Display Active).

2. In the SDSF DA screen, enter a “?” next to the TCPIP job to get a list of data set definitions.

3. From the list of data set definitions, select JESJCL by placing an “s” next to it.

4. For the IBM stacks, the DD statement of the //SYSTCPD gives the DSN of the profile data set which TCP/IP reads for the initialization parameters. Browse the TCP/IP profile data set from ISPF.

5. For the TCP access stacks, the DD statement of the //SYSPARM gives the DSN of the profile data set, which TCP/IP reads for the initialization parameters. Browse the TCP/IP profile data set from ISPF (probably named ACPCFGxx) for the NETWORK HOST statement.

6. Within the TCP/IP profile data set, do a FIND HOME to go to the IP address. The IP address appears in dotted notation (such as 199.72.46.202).

Testing the TCP Connection Ping is a simple utility program, included in all TCP/IP implementations. To try out the connection from one computer to another, enter the following at a TSO Ready prompt:

PING xx.xx.xx.xx

Replace the x’s with the IP address of the target computer, that is, the computer you’re trying to reach.

If Ping is successful on MVS, you will see a message like the following:

EZA0463I PING: Ping #1 response took 0.014 seconds. Successes so

far 1.

If Ping is unable to reach the target, you will see a message like the following:

EZA0464I PING: Ping #1 timed out

24 IBM MVS Endpoint

If you see this message, the Ping failed, and you may have the wrong address, a configuration problem, a network problem, or the target computer may not even be powered on.

Make sure that you can run Ping successfully from the Chariot or Qcheck Console or the End2End server to each computer serving as Endpoint 1, and between each pair of endpoints involved in a test, before starting your testing with TCP/IP.

Sockets Port Number TCP/IP applications use their network address to decide which computer to connect to in a network. They use a Sockets port number to decide which application program to connect to within a computer.

The TCP/IP Sockets port for the endpoint is 10115. This port number is used during the initialization of a test; during the actual running of the test, other port numbers are used. If the script specifies “port_number=AUTO” on the CONNECT_ACCEPT command, additional ports are dynamically acquired from the protocol stack. Otherwise, the endpoint issuing the CONNECT_ACCEPT commands (usually Endpoint 2) uses the port number specified in the script.

Changes Required for TCPAccess (NetworkIt:TCPAccess)

For the TCPaccess protocol stacks, you must configure the port number to a higher number than the current maximum default port number of 8891. Chariot uses port number 10115 as the port number on which it listens.

For TCPaccess version 4.1: in the “TCPICS.V410.PARM(ACPCFGxx)” member, code the following lines:

TIB PROTOCOL(TCP) TADDRUSE(1:4095) TADDRASGN(4096:10200)

TIB PROTOCOL(UDP) TADDRUSE(1:4095) TADDRASGN(4096:10200)

In these instructions, “TCPICS.V410” is an example of a high-level qualifier assigned to the TCPaccess datasets during installation. Similarly, “xx” refers to the suffix chosen for the customized version of the PARM dataset members.) For TCPaccess version 4.1, you must restart the stack in order for these parameters to take effect.

Additional Configuration for OS/390 IBM’s TCP/IP requires some additional configuration, when using OS/390 v2.5 and higher. Without these changes, the MVS endpoint is unable to open a port on TCP/IP on systems running OS/390 2.5 and higher. After making configuration changes, MVS must be restarted because TCPIP is more tightly coupled to the OS in version 2.5 and higher.

Look in the BPXPRMnn sys1.parmlib member. This is the statement in BPXPRMnn that is most likely causing problems:

NETWORK DOMAINNAME(AF_INET) DOMAINNUMBER(2) MAXSOCKETS(1000)

TYPE(CINET)

INADDRANYPORT(5000) INADDRANYCOUNT(4000)


These last two parameters tell TCP/IP to reserve ports for use with port 0, starting with port 5000 and reserving 4000 ports. If you are trying to use any ports in this range without these parameters, you are out of luck.

Here is the relevant information from the OS/390 v2.6 MVS Initialization and Tuning Reference (IBM publication number SC28-1751):

NETWORK DOMAINNAME(sockets_domain_name)

DOMAINNUMBER(sockets_domain_number) MAXSOCKETS(number)

TYPE(type_name) INADDRANYPORT(starting_port_number)

INADDRANYCOUNT(number_of_ports_to_reserve)

The NETWORK statement specifies that a socket physical file system domain should be readied for use. Provide a NETWORK statement for each socket file system domain to be initialized:

• For AF_UNIX file systems, include a FILESYSTYPE statement specifying TYPE and a NETWORK statement with a matching TYPE.

• For common INET, include a FILESYSTYPE statement specifying TYPE and a NETWORK statement with a matching TYPE that specifies INADDRANYPORT and INADDRANYCOUNT. See “Configuring for Common INET” on page 23 for more information.

• For TCP/IP, include a FILESYSTYPE statement with TYPE and a NETWORK statement with a matching TYPE.

DOMAINNAME(sockets_domain_name) The 1- to 16-character name by which this socket file system domain is to be known.

DOMAINNUMBER(sockets_domain_number) A number that matches the value defined for this domain name. The currently supported values for this field are as follows:

1 (corresponds to the name AF_UNIX).

2 (corresponds to the name AF_INET).

Provide a Configuring for Common INET statement for each socket file system domain to be initialized. For socket file systems, there should always be a FILESYSTYPE statement and a matching Configuring for Common INET statement.

The following table shows some supported domain names, domain numbers, and their associated entry point names. See the documentation for the physical file system you are using to get the correct entry point name.

Domain Name Domain Number Entry Point

AF_UNIX 1 BPXTUINT

AF_INET 2 BPXTIINT, BPXTCINT, BPXTLINT

26 IBM MVS Endpoint

MAXSOCKETS(nnnnn) The maximum number of sockets supported by this file system. This is an optional parameter. You can specify a value from 0 to 64498. The maximum value for this field is defined by each domain. If a value larger than the maximum is specified, an informational message is issued and the value used is the maximum. If this parameter is omitted, a default value of 100 is used.

Make sure that this number is large enough for socket connections for all applications using your OS/390 UNIX environment. This upper limit is not adjustable and is enforced by the system.

TYPE(type_name) Specifies the name of a file system type identified in a FILESYSTYPE statement. The TYPE(type_name) must be the same as the TYPE(type_name) parameter on a FILESYSTYPE statement.

TYPE is a required parameter. The name is 1 to 8 characters; the system converts the name to uppercase.

INADDRANYPORT(starting_port_number) Specifies the starting port number for the range of port numbers that the system reserves for use with PORT 0, INADDR_ANY binds. This value is only needed for INET.

The starting_port_number is a decimal value from 1024 to 65535. Ports 1 to 1023 are well-known ports that cannot be reserved for use with PORT 0, INADDR_ANY binds. The default is 0: No ports are reserved.

INADDRANYCOUNT(number_of_ports_to_reserve) Specifies the number of ports that the system reserves, starting with the port number specified in the INADDRANYPORT parameter. This value is only needed for INET.

The number_of_ports_to_reserve is a decimal value from 1 to 4000. The default is 0: No ports are reserved.

Updating Endpoint JCL Values The PARM keyword of the EXEC PGM statement in the endpoint JCL data set consists of seven parameters: APPLID, DEBUG, MAXRPLS, MAXCNOS, NONSWAP, TCP, and WTOR.

Here are some guidelines for setting these parameters:

• If you’re using TCP/IP, set the TCP parameter.

• If you’re using APPC, update the APPLID parameter.

• If you’re not using APPC, omit APPLID and set MAXRPLS and MAXCNOS to 0.

• The PARM string is limited by JES to 100 bytes in length.


Omit MAXRPLS and/or MAXCNOS if you are short on string space (and their defaults are acceptable) or use shorter ACB names in the APPLID. If you remove MAXRPLS or MAXRPLS from the PARM string, be sure to comment out their assignment statements in the JCL, to avoid JCL symbol definition errors.

APPLID (for use with APPC) Provide a list of ACB names (LU names), known to VTAM, by which this endpoint can be reached. The endpoint can use up to 8 ACB names.

See “Using Multiple ACB Names (LU Names)” on page 21 for details.

DEBUG (for use with all protocols) Include this parameter with a value of 1 or 2 only when necessary to collect information for use by the NetIQ Customer Support team (because it will impact performance).

The following values are allowed:

DEBUG value

Description

0 This value provides the best performance and the smallest amount of overhead. It is equivalent to omitting the DEBUG parameter. Default value.

1 This value activates the SAS/C Compiler run-time trace and warning messages. Use of this option increases the endpoint’s resource consumption; it should be used only when the endpoint exhibits a repeatable problem or abend.

2 This value activates the SAS/C Compiler run-time trace and warning messages, along with the quit-execution-on-warning flag. This option increases the endpoint’s resource consumption and should only be used when an abend dump is needed when a warning message is issued. This option causes the endpoint to terminate when a warning message is issued.

MAXRPLS (for use with APPC) Provide a value corresponding to the maximum number of APPC connections. An RPL is a “Request Parameter List,” used by VTAM applications to make requests of VTAM. The endpoint requires 3 RPLs per thread using APPC communications. Therefore, 600 RPLs will support 200 APPC threads. A test with a single connection doing loopback uses 2 threads.

The endpoint internally has no knowledge of protocol or why a thread is being started. Most of the time this has no effect on TCP/IP tests. However, on a mixed test with the maximum number of APPC threads running, the TCP/IP thread will not be able to start. This is because the endpoint internally checks to make sure that enough RPLs are available to support another APPC thread. As long as there are enough RPLs to start at least one APPC thread, there is no limit on TCP/IP threads.

The default value is 600.

28 IBM MVS Endpoint

MAXCNOS (for use with APPC) Indicate how many CNOS buffers are to be allocated at initialization. One CNOS buffer is required for each APPLID, partner LU NAME, and mode name session that is started with the MVS endpoint.

The default value is 100.

TCP (for use with TCP and UDP) • For IBM stacks, supply the job name for the TCP/IP stack. The string

“TCPIP” is the default.

• For TCP access stacks, supply the subsystem name. The string “ACSS” is the default.

Change this value if your administrator has renamed the stack proc, or if you’re using a different, supported TCP/IP stack.

WTOR (for use with all protocols) This parameter specifies whether or not the endpoint should display a Write-To-Operator-Reply (WTOR) at the MVS console. This reply is used to query the endpoint for status information, and to terminate the endpoint.

The allowed values are as follows:

WTOR value Description

0 This value causes the endpoint not to display the operator reply.

1 This value causes the endpoint display the operator reply. This is the default value.

If you choose not to have the WTOR displayed, you cannot query the status of the endpoint as described in the section “Requesting Status Information” on page 39. To stop the endpoint, you must also use the MVS CANCEL command.

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 the MVS endpoint for improved performance.

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.


1. 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 throughput we’ve seen is 3.8 Mbps, which can be bested by almost any Pentium PC.

2. With a 300 MIPs computer and a good channel attachment, we’ve seen throughput of 12 MBps (96 Mbps).

As we continue to upgrade the endpoint software, we strive for as little CPU overhead as possible in all of our endpoints. An idle MVS endpoint consumes 0.0% CPU. 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.

You might see some operating-system problems with the MVS endpoint during streaming tests if you’re running at a very fast rate or with many pairs using small datagram buffer sizes. With these tests, the TCP/IP stack may lock up for a period of time. MVS is usually able to recover after a few minutes.

We determined from our own testing that in such cases the Endpoint 2 computer was overwhelmed with thousands of small datagrams, which the TCP/IP network stack could not process quickly enough. Either the RAM (in our test case, the computer had 64 MB of RAM) or CPU power needs to be increased to handle the load.

MVS Channel Attachments We’ve received excellent feedback from IBM and Cisco on the throughput that is possible with 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 High Performance Routing (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.

30 IBM MVS Endpoint

• MVS/VTAM--Escon channel--IBM 3745 -- LAN Expect up to 2 MBps (16 Mbps) We understand that the 3745 family has an internal bus based on 16 Mbps token-ring technology, limiting the throughput through these devices.

• MVS/VTAM--Escon channel--IBM 3172 -- LAN Expect up to 4 MBps (32 Mbps) 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.

• MVS/VTAM--Escon channel--IBM 2216 -- LAN 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.

The vendors have published good information on mainframe performance expectations. See www.cisco.com/warp/public/cc/pd/ifaa/ifpz/chifpz/tech/cipps_wp.htm for Cisco’s performance comparisons between its 7500 CIP Router family and IBM’s 2216 (covering both APPC and TCP/IP). See www.networking.ibm.com/216/2216perf.html for performance information about IBM’s 2216 and www.networking.ibm.com/prodguide/server-access.html for product and performance information about IBM’s 3745 and 3746.

Performance of Partner Endpoints We offer APPC support today on our IBM OS/2, Windows 95, Windows 98, Windows Me, Windows NT/2000/XP, and IBM 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 6.0 or later, when testing APPC performance. Compared to the IBM’s older Communications Manager/2 version 1.11, throughput has been significantly improved.

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


http://www.cisco.com/warp/public/cc/pd/ifaa/ifpz/chifpz/tech/cipps_wp.htm

http://www.networking.ibm.com/216/2216perf.html

http://www.networking.ibm.com/prodguide/server-access.html

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 www.microsoft.com/sna 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 measuring, consider the following 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. For more information, see the previous discussion of MVS Channel Attachments (on page 30).

• 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 easy to set on IBM’s Communications Server/2 for OS/2.

− The default value for IBM’s CommServer for Windows NT version 1.0 is too low, resulting in poor performance. It can be changed in the ASCII text configuration file.

32 IBM MVS Endpoint

http://www.microsoft.com/sna

Running MVS Endpoints The following sections describe starting and stopping an endpoint, as well as some of the messages and information available after testing with the MVS endpoint. You can run the MVS endpoint as either a job or as a started task (or proc). We recommend that you run it as a job mainly for testing out your installation of the endpoint. It is recommended that you convert it to a started task so that you gain the following benefits:

• It can be started automatically.

• You can gain control of its dispatch priority on MVS. In other words, you can make it run at the same priority as the application you are emulating.

Starting an MVS Endpoint The endpoint is not started automatically when the endpoint is installed or when MVS is started. Instead, the endpoint is started via a job or as a started task. The installation creates the JCL for a job; the same JCL can be used for the started task after commenting out 3 lines in the JCL.

If you run a test with the MVS endpoint as a job and then run it as a started task, you may see slightly different numbers in your results. MVS internally handles jobs and procs at different priorities; how these behave depends on your local system configuration.

Starting an MVS Endpoint as a Job Here are the steps for starting an endpoint job on MVS from ISPF Data Set List Utility (option 3.4):

1. Enter “e” next to the NETIQ.ENDPOINT.JCL data set (to edit it).

2. Edit.

3. Enter “SUB” next to the ENDPOINT member (to submit it).

You should see a message like the following when the endpoint job is submitted:

IKJ56250I JOB SUBMITTED(...)

Here’s how to tell if the job started successfully from SDSF:

1. Enter “da” (to display active jobs).

2. Enter “?” next to the ENDPOINT jobname.

3. Enter “s” next to the SYSPRINT ddname.

There should be an active JOBNAME named ENDPOINT. The CPU% should be 0.00, except when the endpoint is starting up or actively running a test.

If the ENDPOINT job is not active, it failed to start successfully. Here’s how to tell what happened if the endpoint job failed from SDSF:


1. Enter “o” (for the JES output queue).

2. Enter “?” next to the ENDPOINT jobname.


A single running copy of the endpoint program can handle one or multiple concurrent tests. If the endpoint program is already running and you try to start another copy, you get the following error message, “CHR0183: The endpoint program is already running. Only one copy is allowed at a time.”

Starting an MVS Endpoint as a Started Task We’ve made it easy to start the MVS endpoint as a started task. It uses the same JCL as when running a job (with the deletion of 3 lines). This procedure may require the assistance of your MVS systems programmer and/or security administrator.

1. First, verify that the endpoint runs correctly as a job. Run some tests from the Chariot Console or verify your connection in End2End, using the network protocols of your choice, with the MVS endpoint in the roles of Endpoint 1 and Endpoint 2.

See “Starting an MVS Endpoint as a Job” on page 33 for details.

2. Edit the endpoint JCL data set, removing or commenting out the JOB, PEND, and EXEC PROC statements. In our example, the JCL data set is named NETIQ.ENDPOINT.JCL(ENDPOINT).

3. Copy the modified NETIQ.ENDPOINT.JCL(ENDPOINT) to SYS1.PROCLIB or an equivalent proclib in your JES proclib concatenation.

4. Start the endpoint proc from the MVS Console by entering:

S ENDPOINT

5. As in the first step, verify the correct operation of the endpoint.

6. Having verified the successful operation of the endpoint proc, see “Stopping an MVS Endpoint” on page 37 for ways to stop the endpoint.

You may want to have the endpoint proc started automatically each time MVS is IPLed. To do this, you may need the assistance of your MVS administrator to gain authorization to perform the following steps, which will allow the endpoint to start automatically (assuming you’ve completed the preceding steps for converting a job to a proc):

1. Copy the NETIQ.ENDPOINT.JCL(ENDPOINT) to SYS1.PROCLIB or an equivalent DD concatenation PROCLIB.

2. SYS1.PARMLIB(IEASYSxx) will have a line that looks like the following:

CMD=00, COMMND00

Edit the member referred to in IEASYSxx. In this example, it would be SYS1.PARMLIB(COMMND00). Add the following line to COMMND00:

34 IBM MVS Endpoint

COM=‘S ENDPOINT’

3. APF authorize the NETIQ.ENDPOINT.LOADLIB. If you do not have dynamic APF authorization turned on for MVS 5 or above, you must IPL MVS to pick up authorization changes. This is only required if you specify NONSWAP=1 in the JCL PARM field.

4. The next time you start MVS, the endpoint is automatically started. If you wish to start the endpoint now, enter ‘S ENDPOINT at the MVS Console command prompt or /S ENDPOINT from SDSF LOG.

User-Defined CMP Files The MVS endpoint supports user-defined .cmp files (that is, data compression files named Userxx). Data compression files (including a listing of the pre-defined files and details on user-defined files) are described in the Application Scripts manual.

The following steps are required to implement support for a user-defined .cmp file:

1. Create the user-defined .cmp file.

2. Store the .cmp file in the HFS.

3. Update the JCL to include the .cmp file.

More information on each of these steps follows.

Create the user-defined CMP file. Create the .cmp file, using whatever tools or editors best suit your need. You can create the file on a PC, or in an MVS data set.

Store the CMP file in the HFS. In order for the .cmp file to be used, it must reside in an MVS OpenEdition Hierarchical File System (HFS). You can create the file in the HFS directly, by logging into the OMVS shell, or you can ftp the file to the HFS from another system. You can also create the file in a traditional MVS data set or PDS member and copy it over to the HFS using the OPUT command, issued from TSO.

In the following example, the OPUT command is used to perform a binary copy of a user-created .cmp file from 'P390.CMP(USER01)' to /u/p390/user01.cmp in the HFS:

OPUT `P390.CMP(USER01)' '/u/p390/user01.cmp'

To upload the file via ftp, do a binary transfer.

For more information on working with files in the HFS, see the IBM manual OS/390 Unix System Services User Guide (SC28-1891).


Update the JCL to include the CMP file You can now specify the CMP file from within your script files. All that remains is to update the JCL for the endpoint so that it knows about the new file. Assuming a file named User01.cmp, the following DD statement would be added to the endpoint JCL:

//USER01 DD PATH='/u/p390/user01.cmp',PATHOPTS=ORDONLY

The PATH= parameter specifies the path of the file in the HFS.

Limitations with User-Defined Ports Chariot’s short-connection scripts, such as Inquirys.scr and Credits.scr, are designated with an "S" in their names. These scripts repeatedly set up and take down network connections once per transaction (whereas the long-connection scripts Inquiryl.scr and Creditl.scr use a single connection to execute multiple transactions). If short-connection scripts are run with the MVS endpoint in tests where you’ve also specified the port numbers, the tests will fail. In the SYSTEM DD of the ENDPOINT job, you’ll see a message like the following:

LSCX904 **** WARNING **** ERRNO = EADDRINUSE

This problem occurs due to a limitation in the IBM TCP/IP stack, which will continue to keep a socket connection active for up to two minutes after it has actually been closed by the application.

Changing the Endpoint's Priority The MVS endpoint can only represent applications that run at the same level of priority. The priority at which the endpoint is run is defined in the appropriate IEAIPSxx and IEAICSxx SYS1.PARMLIB member.

Look up the Performance Group in the SYS1.PARMLIB(IEAICSxx) member for the application you want to emulate (such as CICS). Make similar entries into SYS1.PARMLIB(IEAICSxx) for the ENDPOINT proc.

Many other parameters can influence the endpoint’s priority on MVS. We have provided only some basic information. For more on tuning, consult your MVS systems programmer and the IBM publication titled MVS Initialization and Tuning Reference (IBM publication number SC28-1752).

How to Tell If an MVS Endpoint Is Active Use SDSF DA to look for the endpoint job; there should be an active JOBNAME named ENDPOINT. The CPU% should be 0.00, except when the endpoint is starting up or actively running a test.

Disabling Automatic Startup To disable the automatic starting of the endpoint, remove the line you added in the discussion of the endpoint as a proc.

36 IBM MVS Endpoint

SYS1.PARMLIB(IEASYSxx) will have a line that looks like the following:

CMD=00, COMMND00

Edit the member referred to in IEASYSxx. In this example, it would be SYS1.PARMLIB(COMMND00). Remove the following line from COMMND00:

COM=‘S ENDPOINT

Running Loopback Tests with the MVS Endpoint You can run tests where MVS is serving the roles of both Endpoint 1 and Endpoint 2 (loopback testing).

• For TCP and UDP, you can use the same IP addresses or domain names in the Endpoint 1 and Endpoint 2 network addresses at the Chariot or Qcheck Console or the End2End server.

• For APPC, you cannot use the same ACB name (LU name) for both the Endpoint 1 and Endpoint 2 network addresses. However, you can run tests between two different ACBs in the same computer. See “Using Multiple ACB Names (LU Names)” on page 21 for guidance on defining multiple ACB names to VTAM.

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.

Stopping an MVS Endpoint Like all applications involved with networks and communications, the endpoint program can possibly get “hung,” with no way to terminate it. The endpoint job or proc can be stopped using the following techniques.

You can stop the endpoint proc in three different ways:

• Reply to the endpoint’s outstanding WTOR (Write To Operator Reply):

R xx,CLOSE

where xx matches the reply number at the MVS Console.

• To stop the endpoint proc from the MVS Console, enter:

C ENDPOINT

• Purge it.

− Enter “da” (to display active jobs).

− Enter “p” next to the ENDPOINT jobname.


You will need to stop the MVS endpoint if you stop the protocol stack to ensure that you do not generate excessive messages printed to the Spool or the MVS Console. The MVS Performance endpoint will continue to connect to the protocol stack every 10 seconds, and if the stack is not started, the endpoint will generate an error message. You need to restart the endpoint anytime you recycle the protocol stack to be sure that you do not generate these error messages.

Logging and Messages If you are running the endpoint job on MVS, you will see information about the running tests and error messages (when appropriate). While most error messages encountered on an endpoint are returned to the Chariot or Qcheck Console or the End2End server, some may be logged to disk. Errors are saved in a data set named NetIQ.Endpoint.log. To convert the binary error log to readable format, use the program named FMTLOG. FMTLOG reads from a binary log file, and writes its formatted output.

Here are the steps for starting the FMTLOG job on MVS from ISPF:

1. Enter “e” next to the NETIQ.ENDPOINT.JCL file (to edit it).

2. Edit.

3. Enter “SUB” next to the FMTLOG member (to submit it).

You should see a message like the following, when the endpoint job is submitted:

IKJ56250I JOB SUBMITTED(...)

Here’s how to tell if the job started successfully from SDSF:

1. Enter “da” (to display active jobs).

2. Enter “?” next to the FMTLOG jobname.


4. If the FMTLOG job is not active, it failed to successfully start. Here’s how to tell what happened if the endpoint job failed from SDSF:

− Enter “o” (for the JES output queue).

− Enter “?” next to the FMTLOG jobname.

− Enter “s” next to the SYSPRINT ddname.

This endpoint performs extensive internal cross-checking to catch unexpected conditions early. If an assertion failure occurs, detailed information is written to the log data set named NETIQ.ENDPOINT.ASSERT. Use “cut and paste” at your PC to capture the information, and return it to NetIQ Technical Support for debugging.

38 IBM MVS Endpoint

Requesting Status Information You can get status information by entering these commands in reply to the endpoint’s outstanding WTOR (Write To Operator Reply):

R xx,ALL

R xx,APPC

R xx,TASKS

R xx,CLOSE

If WTOR=0 is specified on the endpoint JCL, you cannot access status information.

Reply APPC: Provides status information for each of the VTAM ACBs defined using the APPLID= JCL parameter.

For each ACB, the status is O=open or C=closed, with a count of the number of CNOS (Change Number of Sessions) received, the number of currently active RPLs, and the total number of APPCCMDs issued for this ACB.

Buffer counts are also shown as follows:

Buffer Name Buffer Description

RPLS Number of available buffers for RPLs to run APPC tests

CFRE Number of available buffers to receive CNOS requests in the VTAM ATTN exit

TPNS Number of TP names defined for Endpoint 1 tests

TPE2 Number of TP names defined for Endpoint 2 tests

CNOS Number of RPL buffers currently used to receive CNOS requests when CFRE buffers are depleted

ERRQ Number of RPL buffers currently queued containing error information for display to SYSPRINT

Minimum counts are shown for RPLS and CFRE.


Example:

*38 ENDPOINT: REPLY WITH ALL, APPC, TASKS, OR CLOSE R 38,APPC

ACB ENDJBMVS status=O 1 CNOS 0 active RPLs 132 CMDs

ACB ENDJB001 status=O 1 CNOS 6 active RPLs 3127 CMDs




COUNTs 555 RPLS 93 CFRE 1 TPNS 12 TPE2 0 CNOS 0 ERRQ

MINs 546 RPLS 93 CFRE

*39 ENDPOINT: REPLY WITH ALL, APPC, TASKS, OR CLOSE

Reply TASKS: Provides the current number of active threads.

Example:


R 37,TASKS

ENDPOINT: active_threads=24


If the DEBUG=n is non-zero, a list of all active threads is provided in the SYSPRINT JES output. This list also includes the main thread, a reporting thread, and a thread for each enabled protocol.

Reply ALL: Provides both the APPC and TASKS outputs.

40 IBM MVS Endpoint

Example:


R 39,ALL

ACB ENDJBMVS status=O 1 CNOS 0 active RPLs 218 CMDs





COUNTs 602 RPLS 93 CFRE 1 TPNS 0 TPE2 0 CNOS 0 ERRQ

MINs 546 RPLS 93 CFRE

ENDPOINT: active_threads=0


Reply CLOSE: The endpoint job ends, even if threads are active.

Example:

*54 ENDPOINT: REPLY WITH ALL, APPC, TASKS OR CLOSE

R 54,CLOSE

ENDPOINT: close IGNORED. Number threads active = 24

ENDPOINT: Wait for tests to complete or cancel the endpoint job.

*55 ENDPOINT: REPLY WITH ALL, APPC, TASKS OR CLOSE

Getting the Latest PTFs and Service Updates We’ve found that communications software is often fragile. Its developers are constantly working to make it more robust, as the software gets used in an ever-wider set of situations.

We therefore recommend working with the very latest software for the underlying operating system and communications software. Here are the best sources we’ve found for the MVS software used by the endpoints. Additional information is described in the individual endpoint topics in this guide.

See the Support section of the NetIQ Web site for links to the latest software updates.

Updates for IBM MVS IBM posts fixes for MVS, VTAM, and its TCP/IP software directly to the following locations:


• Go to the IBM Web site at http://techsupport.services.ibm.com/s390/support. Select the country from which to download the fixes and then click GO. You will then be allowed to Register or Log in. IBM requires that you have a user ID and password to get service updates for their products. After logging in, you will be able to get the specific fix you need or a cumulative PTF, which includes all fixes IBM has made through a specific date.

• IBM Home Page: www.ibm.com/

• IBM Software Manufacturing Solutions: http://service.boulder.ibm.com/

For fix information from IBM on VTAM and TCP/IP for MVS, see www-4.ibm.com/software/network/commserver/support/fixes/csos390.html.

IBM customers can also access the general support offerings by calling the National Solution Center at 800-992-4777. Fees are applicable, and you may want to call first to get a map of the voice-mail services.

Updates for Computer Associates Computer Associates has purchased Sterling Software (which purchased Interlink Computer Sciences, the makers of TCPAccess, in 1999). The Performance Endpoint for MVS supports two versions of their SOLVE:TCPaccess TCP/IP protocol stack, version 4.1 and 5.2 (formerly known simply as “TCPaccess”). For TCPaccess version 4.1, the following PTFs are required for successful operation:

1. The cumulative PTF 9712.

2. All PTFs up to and including TP6256.

3. Subsequent PTFs TP6263, TP6471, and TP 6497.

4. The files UTP6505.bin, UTP6519bin, and UTP6525.bin from the TCPaccess FTP site. You can get directions on how to download the fixes from the Sterling Software FTP site.

We recommend that you run your systems with the latest maintenance from the software supplier. Sterling Software technical support is currently accessed via the Computer Associates Web site: http://support.ca.com/products/netmgt/netmgt-menu.html - tcpaccess53. SOLVE:TCPaccess customers can also reach the general support offerings by calling Sterling Software at 800 663 6529.

42 IBM MVS Endpoint

http://techsupport.services.ibm.com/s390/support

http://www.ibm.com/

http://service.boulder.ibm.com/

http://www-4.ibm.com/software/network/commserver/support/fixes/csos390.html

http://support.ca.com/products/netmgt/netmgt-menu.html

Chapter 2 Performance Endpoints

This guide contains information about the Performance Endpoints, which are available for more than 20 different operating systems.

All the information you need to install, configure, and run the endpoints in your network is included here and in the printed version of the Performance Endpoints guide. In addition to topics discussing issues common to all the endpoints, these guides also contain information about each operating system, organized in separate chapters.

Endpoint Requirements and Capabilities The following topics describe the software and hardware requirements and the supported functions of the Performance Endpoints, version 4.4.

The latest version of the endpoint software can always be downloaded free from the Internet. A single installable file is available for each operating system. Endpoints are available for downloading at www.netiq.com/support/pe/pe.asp.

You cannot run endpoint software from a CD-ROM; you must install it on a computer.

Operating System and Protocol Stack Support The following tables list the software with which we have tested the Performance Endpoints for each operating system.

Note Versions listed are the earliest, not necessarily the only, versions supported.

Chapter 2 • Performance Endpoints 43

http://www.netiq.com/support/pe/pe.asp

Endpoint OS version TCP, UDP, RTP

IP Multicast version

IPX/SPX stack

APPC stack version

Cobalt RaQ/RaQ2 (MIPS)

Linux v. 2.0 for MIPS

included kernel 2.0.32

no no

Cobalt RaQ3 (x86)

kernel 2.0.32


no no

Compaq Tru64 UNIX

Digital UNIX 4.0B or Compaq Tru64 Unix for Alpha

included v4.0B no no

FreeBSD UNIX

BSD v3.1 included v3.1 no no

HP-UX HP-UX v10.10

included v10.10 no no

IBM AIX AIX v4.1.4 included v4.1.4 no no

IBM MVS MVS/ESA SP v4R2.2

See “MVS TCP/IP Stacks”

no no IBM ACF/VTAM for MVS/ESA v3R4.2

IBM OS/2 OS/2 Warp 4, Warp Connect 3

Download TCP 4.1

Download TCP 4.1

Download Novell Netware Client v2.12

IBM CommServer for OS/2 v4.1

Linux (x86 and MIPS)

kernel 2.0.32


no no

Linux IA-64 kernel 2.4.0test7-42

included kernel 2.4.0test7-42

no no

Microsoft Windows 3.1

Windows 3.1 or Windows for Workgroups 3.11

see “Microsoft Windows 3.1 TCP/IP Stacks”

Chameleon 7.0, as E2

no no

Microsoft Windows 95

Windows 95

included no Download Novell Netware Client v3.21

IBM PComm v4.3 for Windows 95

44 IBM MVS Endpoint



IPX/SPX stack

APPC stack version

Microsoft Windows 95 with WinSock 2

Windows 95 with WinSock 2 installed

Download WinSock 2

included included IBM PComm v4.3 for Windows 95


Windows 98

included included included IBM PComm v4.3 for Windows 98

Microsoft Windows Millennium Edition (Me)

Windows Me

included included included IBM PComm v4.3 for Windows 98

Microsoft Windows NT 4

Windows NT SP 4

included SP3 (IGMPv1) SP4 (IGMPv2)

included IBM PComm v4.3, or IBM CommServer v5.0 (for Windows NT), or Microsoft SNA Server v4.0s for Windows NT

Microsoft Windows NT 4 for Alpha

Windows NT4 SP 3

included SP3 (IGMPv1) SP4 (IGMPv2)

included Microsoft SNA Server for Alpha v4.0 with SP1 or v3.0 with SP2


Windows 2000

included included included IBM PCOMM version 5.0, or IBM CommServer v6.0

Microsoft Windows XP

Windows XP (32-bit)

included included included IBM PCOMM version 5.0, or IBM CommServer v6.0

Microsoft Windows XP (64-bit)

Windows XP (64-bit)

included included no no

Novell NetWare

v3.12 included v4.0 included no




IPX/SPX stack

APPC stack version

SCO UnixWare

UnixWare v2.1

included v7.0 no no

SGI IRIX IRIX v6.2 with patches

included v6.2 no no

Spirent Terametrics

kernel 2.2.11


no no

Sun Solaris for SPARC

Solaris v2.4 included v2.4 no no

Sun Solaris for x86

Solaris v2.4 included v2.4 no no

Microsoft Windows 3.1 TCP/IP Stacks The Microsoft 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 (IP Multicast support requires version 7.0 or later)

• Novell Client 3.1 for DOS and Windows 3.x v2.71

• Novell Client for DOS/Win (VLMs) v1.21

• WRQ TCP Connection for Windows v5.1

Because Windows 3.x lacks thread support, you cannot use the Windows 3.1 endpoint as Endpoint 1 in an IP Multicast test.

MVS TCP/IP Stacks The MVS Performance Endpoint software supports the following TCP/IP stacks:

• TCP/IP versions 3.2 through 3.8, from IBM. Version 2.6 of OS/390 (TCP/IP version 3.5) and higher includes support for IP Multicast testing with Chariot.

• SOLVE:TCPaccess versions 4.1 and 5.2 stack from Sterling Software. A set of PTFs is required for operation with version 4.1.

46 IBM MVS Endpoint

Endpoint Capabilities The following table indicates which endpoints have been tested with and are supported by NetIQ products. Shaded rows indicate endpoints that have been archived at previous versions. For more details on specific product capabilities, see the topics below.

NetIQ Product

Endpoint

Qcheck Chariot End2End Chariot VoIP Assessor

VoIP Manger Call Performance

Compaq Tru64 UNIX

Yes Yes Yes No No

FreeBSD UNIX Yes Yes Yes No No

HP-UX Yes Yes Yes No No

IBM AIX Yes Yes Yes No No

IBM MVS, Windows install

Yes Yes Yes No No

IBM OS/2 Yes Yes Yes No No

Linux for Cobalt RaQ/RaQ2 (MIPS)

Yes Yes Yes No No

Linux for Cobalt RaQ3 (x86)

Yes Yes Yes Yes No

Linux x86 (TAR) Yes Yes Yes Yes No

Linux x86 (RPM) Yes Yes Yes Yes No

Linux IA-64 (TurboLinux)

Yes Yes Yes No No


Yes Yes Yes No No


Yes Yes Yes Yes Yes

Microsoft Windows Me/NT/2000/XP

Yes Yes Yes Yes Yes

Microsoft Windows 98 (Web-Based)

Yes Yes No Yes No

Microsoft Windows Me/NT/2000/XP (Web-Based)

Yes Yes No Yes No

Microsoft Windows XP (64-Bit)

Yes Yes Yes No No


NetIQ Product

Endpoint

Qcheck Chariot End2End Chariot VoIP Assessor

VoIP Manger Call Performance


Yes Yes Yes No No

Novell NetWare Yes Yes Yes No No

SCO UnixWare Yes Yes Yes No No

SGI IRIX Yes Yes Yes No No

Spirent Communications TeraMetrics

Yes Yes Yes Yes No

Sun Solaris (SPARC)

Yes Yes Yes Yes No

Sun Solaris Endpoint (x86)

Yes Yes Yes Yes No

Endpoints for Windows 2000 and Windows XP also support testing with IPv6. Refer to the following topic, “Performance Endpoint Support for Chariot Functions” below for more information.

Performance Endpoint Support for Chariot Functions The following table describes the Performance Endpoint capabilities for the supported operating systems. Shaded rows indicate endpoints that have been archived at previous versions. These endpoints may not support functionality new in the latest versions of NetIQ Chariot.

Endpoint OS IP QoS (DiffServ, GQOS, TOS)

Traceroute CPU Util. VoIP Test Module

IPv6 Test Module

Cobalt RaQ or RaQ2 (MIPS)

TOS no yes no no

Cobalt RaQ3 (x86) TOS yes yes yes no

Compaq Tru64 UNIX TOS no yes no no

FreeBSD UNIX TOS no yes no no

HP-UX TOS yes yes no no

IBM AIX TOS yes yes no no

IBM MVS no no no no no

IBM OS/2 TOS no yes no no

Linux TOS yes yes yes no

Linux IA-64 TOS yes yes no no

48 IBM MVS Endpoint



IPv6 Test Module


no no no no no


no no yes no no


TOS (UDP, RTP)

yes yes no no


GQOS (RSVP), TOS (UDP, RTP)

yes yes yes no

Microsoft Windows Me

GQOS (RSVP)

yes yes yes no


TOS (UDP, RTP)

yes yes yes no


no yes yes no no


DiffServ, GQOS, TOS (via Registry)

yes yes yes yes. See “IPv6 Test Module Support”


yes no yes yes no


yes no yes yes no


DiffServ, GQOS, TOS (via Registry)

yes yes yes yes. See “IPv6 Test Module Support”


DiffServ, GQoS, TOS

yes no yes no

Novell NetWare no no no, v3.12; yes, v4.0

no no

SCO UnixWare TOS (bits 3-5)

no no no no

SGI IRIX TOS no yes no no

Spirent Terametrics TOS yes yes yes no




IPv6 Test Module


TOS yes yes yes no

Sun Solaris for x86 TOS yes yes yes no

IPv6 Test Module Support Currently, testing with version 6 of the Internet Protocol (IPv6) is only supported on endpoints for Windows 2000 and Windows XP (32-bit only). You must first install IPv6 support on these endpoints before you begin testing. You must also purchase the separately licensed IPv6 Test Module.

In addition, Windows 2000 requires a patch called the “Microsoft IPv6 Technology Preview for Windows 2000 Network Protocol Stack,” which you can download from http://msdn.microsoft.com/Downloads/sdks/platform/tpipv6/readme.asp.

Performance Endpoint Support for End2End Functions

The following table shows which endpoint platforms are supported for End2End functions, particularly for the different types of monitoring End2End performs. Shaded rows indicate endpoints that have been archived at previous versions. These endpoints may not support functionality new in the latest version of NetIQ End2End.

Endpoint OS System Mon.

Application Mon.

Network Mon.

Service Mon.

Traceroute Auto-Upgrade

Cobalt RaQ or RaQ2 (MIPS)

no no yes no no no

Cobalt RaQ3 (x86) no no yes no yes no

Compaq Tru64 UNIX

no no yes no no no

FreeBSD UNIX no no yes no no no

HP-UX yes no yes no yes no

IBM AIX yes no yes no yes no

IBM MVS no no yes no no no

IBM OS/2 no no yes no no no

Linux no no yes no yes no

Linux IA-64 no no no no yes no

50 IBM MVS Endpoint

http://msdn.microsoft.com/Downloads/sdks/platform/tpipv6/readme.asp

Endpoint OS System Mon.

Application Mon.

Network Mon.

Service Mon.

Traceroute Auto-Upgrade


no no yes no no no


yes yes yes no no yes


yes yes yes no yes yes


yes yes yes yes yes yes

Microsoft Windows Me





yes no yes no yes no




no no no no no no


no no no no no no




no no yes no yes no

Novell NetWare no no yes no no no

SCO UnixWare no no yes no no no

SGI IRIX no no yes no no no

Spirent Terametrics

no no yes no yes no


yes no yes no yes no

Sun Solaris for x86 yes no yes no yes no


Endpoint Computer Resource Guidelines Determining the computer requirements for a given 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 your computer requirements, you must first define how you plan to use Chariot or End2End. The type of information you need depends upon your usage. The following topics provide recommended endpoint computer specifications according to different testing scenarios.

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 (or better) operating system. The memory you need is based on your operating system. Make sure that you have enough memory at the endpoints so that no swapping takes place while running a test. The following table shows some guidelines in determining the best CPU for different network speeds.

Throughput Recommended computer

less than 100 Mbps PCI-based computer with a 32-bit operating system

100 to 200 Mbps Pentium 166 or greater (consider multiple concurrent pairs)

200 to 500 Mbps Pentium II or greater (consider multiprocessors)

over 500 Mbps latest Pentium III or equivalent, with the latest NICs (consider multiprocessors)

The following observations may help guide your throughput testing.

• Windows NT, Windows 2000, Windows XP, and Linux yield the highest throughput. If you test on one of the Windows OSs with the Chariot benchmark script called High_Performance_Throughput, the endpoints can make use of Microsoft’s WinSock 2 overlapped I/O to achieve much greater throughput on high-speed networks (100 MB and faster). In a test of Gigabit Ethernet throughput using Windows 2000 Server and two Pentium III computers, each having two 933-MHz processors, 1 Gigabyte of RAM, and a single Gigabit NIC, we generated 943 Mbps with six pairs.

• We have also observed some improvements in throughput measurements after changing the TcpWindowSize setting in the Windows NT Registry to 65536. You can set this parameter in the following Registry key:

HKEY_LOCAL_MACHINES\SYSTEM\CurrentControlSet\Services\Tcpip

\Parameters

Set the key as a type REG_DWORD.

Refer to the Windows NT Resource Kit for more information.

52 IBM MVS Endpoint

Calculating Memory Requirements Endpoints are designed to run in any computer that has sufficient memory to run the operating system well. If you plan to use multiple pairs on a single computer, you may want to calculate the number of pairs that will run without causing the operating system to swap either code or data.

The following table can be used to plan for multiple 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 toward zero if the operating system supports swapping. The protocol columns indicate the amount of memory required for a pair of that protocol.

Operating System

Base RAM (in KB)

TCP KB/pair

RTP or UDP KB/pair

SPX KB/pair

IPX KB/pair

APPC KB/pair

MVS 666 25-48 24-52 n/a n/a n/a

NetWare 1100 80-110 320-340 70-100 260-280 n/a

OS/2 1096 50-65 150-170 315-340 150-170 65-90

UNIX (AIX) 1176 132-284 146-296 n/a n/a n/a

Windows 3.1

550 72-600 72-600 n/a n/a n/a

Windows 95/98/Me

1100 40-65 100-145 40-65 55-75 n/a

Windows NT/2000/XP

2076 35-60 160-180 35-60 160-180 n/a

These RAM usage numbers represent sending with the variable send_datatype set to ZEROS. Other send_datatypes require memory buffers roughly equivalent to the disk space of the .cmp file being used. Add 2 KBytes when using send_datatype = NOCOMPRESS. See the Application Scripts guide for more information on script variables.

Endpoint Pair Capacity The following table shows some example pair capacities we have tested on various computers. These pairs ran on a 10 Mbps Ethernet LAN. The values in the pairs columns represent the number of pairs this computer supported as Endpoint 2 for a single test. We used the default values for all tests, with two exceptions: for datagram testing, we lengthened the timeout values, as well as the initial_delay in test scripts.

This table does not represent the full capacities of these operating systems and stacks, just some representative tests we have run in our test lab.


Operating System

Installed RAM

TCP pairs RTP or UDP pairs

SPX pairs IPX pairs APPC pairs

AIX 4.1 64 MB 200 180 n/a n/a n/a

NetWare 4.12

64 MB 500 200 100 100 n/a

OS/2 4.0 32 MB 500 200 20 20 500

Windows 3.1 8 MB 1 1 n/a n/a n/a

Windows 95/98/Me

16 MB 18 100 40 175 n/a

Windows NT/2000/XP

32 MB 500 100 300 100 200

Notes • On Windows NT and Windows 2000, APPC pairs were run using Microsoft

SNA Server.

• On Windows 95, Windows 98, and Windows Me, SPX and IPX pairs were run using Novell Client32 for SPX and IPX.

• On OS/2 4.0, IPX and SPX pairs were run using Novell Client for OS/2.

Chariot now supports larger tests under certain conditions using TCP. See “Internet-Scale Testing” in the User Guide for Chariot for more information about requirements for large tests.

Endpoint Versions With each new release of NetIQ Chariot and End2End, the endpoints are updated to support new functionality. However, because some endpoint operating systems are rarely used or provide limited support for Chariot and End2End features, such as End2End service monitoring, endpoints for a few operating systems have been archived. These endpoints are still made available on the Performance Endpoints CD-ROM and on the NetIQ Web site; however, they may not support the latest capabilities of Chariot and End2End. The Endpoint README file, included in the root directory of the endpoint CD-ROM, provides a list of all available endpoints and indicates their versions if they are different from the current endpoint level.

54 IBM MVS Endpoint

Chapter 3 Endpoint Initialization File

An endpoint initialization file is installed with each Performance Endpoint. With this file, you can do the following:

• Restrict the use of this endpoint to specific Chariot or Qcheck Consoles or End2End servers.

• Control which access attempts are logged in an audit file.

• Change the filename of the audit file.

• Enable only particular protocols on this endpoint for setup connections.

• Change the filename of the End2End safestore file.

• Change the location of the endpoint software used for automatic updating.

On most operating systems, this file is named endpoint.ini (on MVS, see data set HLQ.SLQ.JCL(ENDPTINI), where “HLQ” and “SLQ” are the high-level and second-level qualifiers entered during MVS endpoint installation). This file has the same format and structure on all the operating systems.

Here are the default contents of the endpoint initialization file. You can change these keywords and their parameters to tailor individual endpoints for your needs.

Keyword Parameters

ALLOW ALL

SECURITY_AUDITING NONE

AUDIT_FILENAME ENDPOINT.AUD

ENABLE_PROTOCOL ALL

SAFESTORE_DIRECTORY (the directory where the endpoint is installed)

UPDATE_SERVER endpointupdate.ganymede.com

END2END_SERVER No default

Note For the MVS endpoint, the default filename of ENDPOINT.AUD is ENDPTAUD.

Chapter 3 • Endpoint Initialization File 55

This file is an editable text file. There is a separate copy for each operating system. You might want to make changes to it once, before endpoint installation, which are then incorporated into all the installs for different sets of computers. You can modify this text file before installation by copying the endpoint installation directory for an operating system to a hard drive (preferably a LAN drive), and then modifying the file before running the install from that drive.

We strongly recommend that you make any changes to your endpoint.ini files once, before you install any endpoints, as opposed to installing the endpoints and then going back to each of them and separately modifying each one. If you’re using Windows (32-bit or 64-bit) endpoints, we’ve included a utility to help you edit the endpoint.ini files before installing the endpoints, should you wish to prepare the endpoints for future automatic upgrades. See “Customizing endpoint.ini for Windows Endpoints” on page 59 for more information.

ALLOW This keyword determines which Chariot or Qcheck Consoles or End2End servers can run tests using this endpoint.

To allow any user to run tests on this endpoint, use the ALL parameter, which is the installation default:

ALLOW ALL

However, the default “ALLOW ALL” is NOT RECOMMENDED. Although “ALLOW ALL” makes it easy to install an endpoint and see that it’s running, it also lets any user who can reach the endpoint potentially use that endpoint as a traffic generator. For example, End2End administrators who deploy endpoints widely in their networks probably don’t expect to have those endpoints used in network stress testing.

To allow only specific users to run tests with this endpoint, remove the “ALLOW ALL” line and identify one or more specific Chariot or Qcheck Consoles or End2End servers by their network addresses. You can specify more than one address per protocol. For example,

ALLOW TCP 192.86.77.120

ALLOW TCP 192.86.77.121

ALLOW APPC netiq.johnq

Specify a connection-oriented protocol (that is, APPC, TCP, or SPX) as the first parameter and provide its corresponding network address as the second parameter. Endpoints only listen for incoming tests on connection-oriented protocols, like TCP. Datagram tests are set up and results are returned using their “sister” connection-oriented protocol; thus, UDP tests are set up using TCP, and IPX tests are set up using SPX.

The network address cannot be an alias or hostname; that is, in APPC it must be a fully qualified LU name, in TCP/IP it must be an IP address in dotted notation, and in IPX/SPX it must be an IPX address with hex network address and node address.

56 IBM MVS Endpoint

Endpoints do not respond to End2End endpoint discovery requests unless the IP address of the End2End server is specifically allowed (or unless “ALLOW ALL” is specified). This prevents the user of an End2End server from finding endpoints to which it should not have access.

You cannot use the ALLOW parameter to restrict access from one endpoint to another endpoint. The ALLOW parameter can only be used to permit (or prevent) access from specific Chariot or Qcheck Consoles or End2End servers to the endpoint at which the parameter is defined.

If, for some reason, you need to restrict your endpoint to access only your own computer, specify your own IP network address rather than 127.0.0.1. Specifying 127.0.0.1 (the equivalent of localhost) allows any other user who specifies “localhost” as Endpoint 1 to access your computer as Endpoint 2.

SECURITY_AUDITING This keyword determines which access attempts the endpoint keeps track of in its audit file. Here are the possible parameters:

NONE Nothing is written to the audit file.

PASSED Only access attempts that passed the ALLOW address check are logged.

REJECTED Only access attempts that failed the ALLOW address check are logged.

ALL Both passed and rejected access attempts are logged.

If a test initialization fails for a reason other than address checking, no entry is made in the audit file.

AUDIT_FILENAME This keyword specifies the filespec for the audit file. See SECURITY_AUDITING on page 57 to understand the types of events logged in its audit file. The default filename, in endpoint.ini, is endpoint.aud. If no drive or path is specified, the audit file uses the drive and path of the endpoint program.

This file contains at most two lines for each endpoint pair that is started on this endpoint. These two lines represent the start of an endpoint instance and the end of that instance.

Each line written to the audit file consists of a set of information about the endpoint instance and what it has been asked to do. The information is written in comma-delimited form, so you can load the audit file into a spreadsheet or database. When the audit file is created, an initial header line explains the contents of the subsequent entries.

The following table shows the fields of each entry in the audit file:


Time The date and time when the entry was created, in the local time zone.

Action Whether this entry indicates that an endpoint instance was “Started” or “Ended.”

Endpoint Whether the endpoint is in the role of Endpoint 1 or Endpoint 2.

Protocol of Chariot Console or End2End server

The network protocol used to contact Endpoint 1.

Network Address of Chariot Console or End2End server

The network address as seen by Endpoint 1. If you encounter problems setting up your ALLOW entries, this is the value to use for the protocol address.

Security Result Whether this SECURITY_AUDITING “passed” or was “rejected.” If this is an entry for an “Ended” action, this field is reported as “n/a.”

Endpoint Partner Protocol The network protocol used to run the test with our partner endpoint.

Endpoint Partner Address The network address of our partner endpoint.

ENABLE_PROTOCOL This keyword lets you control which connection-oriented protocols this endpoint uses to listen for setup connections. This does not affect the network protocols, which can be used to run tests. Here are the possible parameters:

ALL

APPC

SPX

TCP

In general, you should use the ALL setting (the default). Specify protocols explicitly to reduce the overhead of listening on the other protocols or if you’re encountering errors when listening on the other protocols.

See the discussion of the ALLOW keyword on page 56 for information about support of the datagram protocols, IPX, RTP, and UDP.

SAFESTORE_DIRECTORY Use the SAFESTORE_DIRECTORY keyword to change the filename of the End2End safestore files, which hold the endpoint’s schedule and any results that have not yet been sent to the End2End server. This keyword has no effect on Chariot users.

For example, the following line causes the endpoint to write its safestore files to the directory d:\NetIQ\Endpoint:

SAFESTORE_DIRECTORY D:\NETIQ\ENDPOINT

58 IBM MVS Endpoint

UPDATE_SERVER This keyword lets you specify the Uniform Resource Locator (URL) of the Web server containing the upgraded Performance Endpoint software. This location is used when the endpoint receives a request from an End2End server to download and install upgraded endpoint software. The URL is the “scheme-specific” part of a valid Uniform Resource Locator, that is, the part after “http://” (see RFC 1738). The default for this keyword is:

UPDATE_SERVER ENDPOINTUPDATE.GANYMEDE.COM

You can also configure your endpoints to automatically download upgrades from a local server. If you don’t want to perform a separate configuration of each endpoint’s endpoint.ini file to change the location of the server, you can modify an executable file included in the endpoint packaging for all Win32 endpoints. When the endpoints are installed, they will automatically use the customized endpoint.ini file you edited. See “Customizing endpoint.ini for Windows Endpoints“ on page 59 for more information.

END2END_SERVER This keyword allows you to specify one or more End2End servers to which the endpoint will initiate a connection. The server is polled every 15 minutes until contacted.

These endpoints are subject to the rules governing inbound endpoints, as defined in the End2End server’s Global Endpoint Defaults.

TCP is the only protocol supported for polling at this time. Here’s the syntax:

END2END_SERVER protocol name | address

Here’s an example of the statement using an IP address. Multiple iterations are allowed:

END2END_SERVER TCP 192.86.77.120

For more information about inbound endpoints, see the User Guide for End2End.

Customizing endpoint.ini for Windows Endpoints Endpoints for Windows can be set up to automatically upgrade themselves. These endpoint computers must be able to contact a Web server where the upgraded software is stored. Although the default Web server for endpoint upgrades is accessible on the Internet at http://endpointupdate.ganymede.com/, in endpoint.ini you can configure the location and directory of any Web server from which the upgraded software can be accessed. See the section titled “UPDATE_SERVER” on page 59 for more information on the endpoint upgrade procedure.


http://endpointupdate.ganymede.com/

We’ve included a utility, gsendw32.exe for Windows and gsendw64.exe for 64-bit Windows, to help you configure endpoint.ini for Windows endpoint upgrades. To modify endpoint.ini before installing an endpoint for Windows, unzip the self-extracting gsendw32.exe (or gsendw64.exe) installation file and make the changes before starting the endpoint installation.

When you click Extract, the endpoint files are extracted (including endpoint.ini) to the directory you selected.

If you are installing over an existing endpoint, the endpoint.ini file is not installed by default. To install the new file, use the following option for SETUP:

SETUP replace_ini

This option reinstalls the endpoint. If an endpoint encounters an error while processing the endpoint.ini file, no one is allowed to use the endpoint in tests. That means no Chariot Console, End2End server, or Qcheck program will be able to run tests with the endpoint.

Configuring Endpoints for Large-Scale Customization To customize features such as automatic upgrades, you must edit the endpoint.ini file for each endpoint. For obvious reasons, you may not want to undertake such a potentially lengthy procedure. You can extract the files located in gsendw32.exe if you need to perform a large-scale customization of endpoint.ini. In addition to WinZip 7.0, you’ll need the WinZip command-line support add-on and WinZip Self-Extractor. Here’s how to use it:

1. Open the file gsendw32.exe using WinZip.

2. Extract the files to a temporary directory.

3. Edit or replace the endpoint.ini that is now in the temporary directory.

4. Using WinZip, create a new archive that contains all the files in the temporary directory.

5. Using the WinZip Self-Extractor, create a self-extracting executable; for the command line to run, enter the following:

SETUP.EXE replace_ini

Now, anyone who executes the new executable you’ve created will automatically have the endpoint installed using the endpoint.ini file that you’ve customized.

To create a file that silently self-installs with a custom endpoint.ini, take the following steps:

1. Open the file gsendw32.exe using WinZip.

2. Extract the files to a temporary directory.

3. Edit or replace the endpoint.ini that is now in the temporary directory.

4. Create a custom response file (say, customer.iss); enter

60 IBM MVS Endpoint

i. SETUP -noinst -r -f1.\customer.iss

5. Using WinZip, create a new archive that contains all the files in the temporary directory.

6. Using the WinZip Self-Extractor, create a self-extracting executable; for the command line to run, enter the following:

SETUP.EXE replace_ini -s -f1.\CUSTOMER.ISS

Now, anyone who executes the file you’ve created will automatically have the endpoint installed using customer.iss as the response file, and the endpoint.ini file installed will also be the customized version you created.

See “UPDATE_SERVER” on page 59 for information on endpoint upgrades.


62 IBM MVS Endpoint

Index

A ALLOW keyword 67 APING 22

and MVS 22 APPC 34

performance with MVS endpoint 34

APPLID (JCL parameter) 31 archived endpoints 64 AUDIT_FILENAME keyword 68 automatic upgrade 70, 71

self-install 73

C calculating memory requirements 62 capacities of endpoints 63 CMPFILES directory

IBM MVS 19

D DEBUG (JCL parameter) 31

E ENABLE_PROTOCOL keyword 69 End2End 59, 71 END2END_SERVER keyword 71 endpoint capabilities

Chariot 57 End2End 59

endpoint capacities 63 endpoint initialization file 65

default keywords 65 endpoint versions 64 endpoint.aud 68 endpoint.ini 65

ALLOW keyword 67

AUDIT_FILENAME keyword 68 customizing for upgrades 71 ENABLE_PROTOCOL keyword 69 END2END_SERVER keyword 71 SAFESTORE_DIRECTORY keyword

70 SECURITY_AUDITING keyword 68 UPDATE_SERVER keyword 70

endpoints automatically upgrading 71

endpointupdate.ganymede.com URL 70

G gsendw32.exe 71, 72 gsendw64.exe 71

H hardware requirements 51

I IBM MVS endpoint 34

APPC 21, 22, 23, 25, 34, 36 changing priority 41 configuring 21 determining if active 42 disabling automatic startup 42 installing 7, 10, 12, 13 logging 44 loopback tests 43 messages 44 OS lockup 34 removing 20 running 37, 38, 39 SAS 9 Sockets port number 28 status information 45

Index 63

stopping 43 TCP 26, 27, 55 uninstalling 20 VTAM 22, 23, 24, 43

IBM MVS software 10 changes in 10 fixes and updates 48

inbound endpoints 71 installation requirements

IBM MVS endpoint 7 installing

IBM MVS endpoints 10, 16 Interlink Computer Sciences 48 IPv6 Test Module

support for 58

J JCL 31

IBM MVS endpoint 31

L loopback 43

IBM MVS endpoint 43

M MAXCNOS (JCL parameter) 32 MAXRPLS (JCL parameter) 32 messages

MVS endpoint 44 Microsoft overlapped I/O 61

O OS/2 7 OS/390 v2.5 7, 29

P PCOMM for Windows 36

R requirements 61 response file 73 restricting access to endpoints 67

S SAFESTORE_DIRECTORY keyword 70 SAS 9 SECURITY_AUDITING keyword 68 software requirements

protocol support 52 SOLVE TCPaccess 48 Sterling Software 48 support for OS

IBM MVS 48

T TCP (JCL parameter) 33 TCPaccess 7

modifying for MVS endpoint 7 versions supported for MVS

endpoint 55 TcpWindowSize 61 throughput 61

generating maximum 61 TLI 7

Sockets API for MVS 7

U uninstall

IBM MVS 20 UPDATE_SERVER keyword 70 upgrade (automatic) 70, 71 user-defined .CMP files 40

V version

of endpoint 64 VoIP Test Module

support for 57 VTAM 10

changes in version 4.4 10

W Windows 3.1 endpoint

TCP/IP stacks 54 WTOR 45 WTOR (JCL parameter) 33

64 IBM MVS Endpoint

performance endpoints -...

Documents