OS/2 Shareware BBS: OtherApp

home *** CD-ROM | disk | FTP | other *** search

/ OS/2 Shareware BBS: OtherApp / OtherApp.zip / aping.zip / aping.doc < prev next >

Wrap

Text File | 1993-05-31 | 105KB | 2,037 lines

COPYRIGHT The program to which this file relates contains source code made available by IBM on an AS IS basis. Anyone receiving the source code is considered to be licensed under IBM copyrights to use the IBM-provided source code in any way he or she deems fit, including copying it, compiling it, modifying it and redistributing it, with or without modifications. No license under IBM patents or patent applications is to be implied from this copyright license. Any user of the program should understand that IBM cannot provide technical support for the program and will not be responsible for any consequences of use of the program. Any person who transfers the source code or any modified version of the source code must include the IBM copyright notice, this paragraph and the preceding two paragraphs in documentation accompanying the source code. AUTHOR Peter J. Schwaller Internet: pjs@vnet.ibm.com CompuServe: 76711,371 IBM VNET: PJS at RALVM6 Phone: (919) 254-4376 IBM Tie-line: 8-444-4376 Date: May 6, 1993 Version: 2.37 +---------------------------------------------------------------------------+ | | | Availability | | | +---------------------------------------------------------------------------+ This sample program and source files are also available on CompuServe through the APPC Information Exchange. To get to the APPC forum just type 'GO APPC' from any CompuServe prompt. The samples are available in the Sample Programs library section. Just search on the keyword CPICPGMS to find all the samples in this series. Updates for the sample programs and support for many more CPI-C platforms will also be made available on CompuServe. +---------------------------------------------------------------------------+ | | | Terminology | | | +---------------------------------------------------------------------------+ TERM DEFINITION TRANSACTION An exchange between two programs that accomplishes a particular action or result. Transaction programs are written in pairs, with both sides of the transaction cooperating to achieve a result. The sides of a transaction program are known as "client" and "server." Examples of transactions are: o sending a simple message o executing a specified procedure or task o updating a database entry CLIENT Identifies the initiator of a transaction. The client must specify the name of the other side of the transaction, known as the server. The term client can refer to either a program or a computer. SERVER Identifies the receiver of a transaction. The server does not need to know the name of the client side of the transaction. PARTNER COMPUTER Identifies the "other" side of a transaction. The partner of the client is the server, and vice versa. DESTINATION The name used on the client to identify the server. APPC PLATFORM Refers to the APPC implementation code running on a given computer. +---------------------------------------------------------------------------+ | | | User's Guide | | | +---------------------------------------------------------------------------+ +---------------------------------------------------------------------------+ | | | What Is APING? | | | +---------------------------------------------------------------------------+ APING is a CPI-C program that should be the first program you configure and run when first configuring APPC on your computer. APING exchanges data packets with a partner computer, and times how long the data transfer takes. It can be used to get a coarse measure of the session setup time between two computers, and the throughput and turnaround time on that APPC session. APING can be used to determine whether a session can be set up between two computers, and will display extensive error information if session allocation fails. APING is made up of two transaction programs; APING, which runs on the client side, and APINGD, which runs on the server side. +---------------------------------------------------------------------------+ | | | Using APING | | | +---------------------------------------------------------------------------+ The simplest way to use APING is to specify only the partner destination name. For example, you can start APING with: APING destination What you actually specify in place of "destination" is described below. Running the APING program will result in a session allocation, which will be timed. Then APING will send 100 bytes to the partner, and receive the same number of bytes, which will also be timed. This will be done twice, since the first timing is likely to include process startup time on the partner side. The following describes all of the APING parameters: APING destination [optional parameters] The destination is the only required parameter. You may specify any number of the additional parameters. If you specify any parameter more than once, only the last parameter value will be used. PARAMETER EXPLANATION destination Identifies the partner computer on which the APINGD server program runs. May be either a CPI-C symbolic destination name or a partner LU name. If the destination is a CPI-C symbolic destination name, it must be 1 to 8 characters and must be configured in your platform's symbolic destination name table (see Configuration Guide below). If the destination is a partner LU name, the format varies from platform to platform. See the Configuration Guide section for your platform for more information about configuring and specifying partner LU names. -m mode_name mode name (default: "#INTER") -t tp_name the TP name to start on the partner (default: "APINGD") -s N N is the size of the packet transmitted (default: 100 bytes) This is the number of bytes sent in each Send call by each side. You may specify a value from 0 to 32767. -i N N is the number of iterations done (default: 2) The number of iterations will be seen in the output as the number of sets of timing information that is shown. You may want to increase this number to get a larger sample of timings. You may specify a value from 1 to 32767. -c N N is the number of consecutive packets sent by each side (default: 1) This is the number of Send calls issued by each side before giving the partner permission to send. For each iteration, each side will make this number of Sends, each of the specified packet size. You may specify a value from 1 to 32767. -u userid This is the userid that will be sent to the partner. The userid can be 1-8 characters in length. You should use this parameter when the destination transaction program has been configured to require security. One indication that the destination transaction program requires security is a CPI-C return code of XC_SECURITY_NOT_VALID. Specifying this parameter implies the conversation will use CPI-C security=PROGRAM. A password must also be specified. If a userid is specified without a password, APING will prompt the user for a password. -p password This is the password that will be send to the partner. The password can be 1-8 characters in length. -n This parameter forces APING to use NO security on the conversation. (CPI-C security=NONE). This should be used when you receive a CPI-C return code of XC_SECURITY_NOT_VALID, but the destination transaction program is not configured to require security. -1 Only send data from client to server (no echo). Note that the flag is a numeral one, not the letter L. The following illustrates the simplified line flows that result when APING is started with the following parameters: APING destination -s 10000 -i 2 -c 4 LOCAL COMPUTER PARTNER COMPUTER Allocate ---------------> Accept Conversation Confirm ---------------> Confirmed Send(10000) ---------------> Receive Send(10000) ---------------> Receive Send(10000) ---------------> Receive Send(10000) ---------------> Receive Receive <--------------- Send(10000) Receive <--------------- Send(10000) Receive <--------------- Send(10000) Receive <--------------- Send(10000) Send(10000) ---------------> Receive Send(10000) ---------------> Receive Send(10000) ---------------> Receive Send(10000) ---------------> Receive Receive <--------------- Send(10000) Receive <--------------- Send(10000) Receive <--------------- Send(10000) Receive <--------------- Send(10000) Deallocate +---------------------------------------------------------------------------+ | | | APING Output | | | +---------------------------------------------------------------------------+ The output from the APING program is similar to the following: APING version 2.37 APPC echo test with timings. by Peter J. Schwaller (pjs@ralvm6.vnet.ibm.com) Allocate duration: 0 ms Program startup and Confirm duration: 720 ms Duration Data Sent Data Rate Data Rate (msec) (bytes) (KB/s) (Mb/s) -------- --------- --------- --------- 60 64000 1041.7 8.333 30 64000 2083.3 16.667 Totals: 90 128000 1388.9 11.111 Duration statistics: Min = 30 Ave = 45 Max = 60 The Allocate duration is how long it takes for the Allocate call to return to the program. The next call in APING is a Confirm call, which is timed to determine the approximate program startup time of the partner transaction program. The number of "Ping duration" lines will be equal to the number of iterations requested (see the -i parameter above). In this case, the default of 2 was used. The last output line provides a summary of the ping duration lines already displayed. The minimum, maximum and average ping duration is displayed in milliseconds. The overall data rate for all pings is calculated and displayed. Note that on some platforms the timer resolution is one second, or 1000 milliseconds. +---------------------------------------------------------------------------+ | | | Configuration Guide for APING | | | +---------------------------------------------------------------------------+ The APING program consists of two sides: the client computer side and the server computer side. On the client computer side, the user starts up the APING program and specifies what actions should be taken. As a result, the APINGD program is started on the server computer side. The APING and APINGD programs then communicate using CPI-C and complete the transaction. In order to get the client computer and the server computer to talk to each other, both computers must be configured. This configuration involves defining certain APPC information to the APING programs and to the APPC platform on the computer. The rest the Configuration Guide is divided into the following sections: o APPC Configuration Overview This section describes the APPC information that must be provided to the APPC platform. If you are not familiar with APPC terminology or configuration, you should read this section. o Configuration Information for Specific Platforms These are the actual steps that should be done on the client computer and server computer. The directions are grouped by APPC platform. You should find the section for your platforms, and follow the steps indicated. The following platforms are described in this Configuration Guide: - Networking Services/DOS - Networking Services/2 or Extended Services - VM SP 6 or VM ESA - AS/400 - MVS - AIX SNA Services +---------------------------------------------------------------------------+ | | | APPC Configuration Overview | | | +---------------------------------------------------------------------------+ In order to successfully communicate with APPC from one computer to another, you need to configure some information in your APPC platform. This information consists of: o How to physically connect to another computer. You tell your APPC platform how to physically connect to another computer by defining a link. The link definition tells APPC information about how to connect to the partner computer, including data link control information. The data link control represents the physical connection (token-ring, SDLC, Ethernet, etc.) between two computers. To connect to the partner computer, the APPC link definition specifies both a data link control and addressing information specific to that data link control. For example, if you are using token ring as your data link control, you will need to specify a token ring address in your link definition. Some data link controls, may not require any address information, since the partner computer is implied to be on the other end of the physical connection. This is common with SDLC leased lines. o How to identify and find the correct server computer. Computers are identified in APPC by their fully qualified LU name. The fully qualified LU name consists of two parts: a network name and an LU name, concatenated with a period. For example: USIBMNR.NR55069I Both the client and server computers must have fully qualified LU names defined. LU names are viewed relative to the computer on which they are defined: there are local LUs and there are partner LUs which are on partner computers. The local LU name for any given computer is the partner LU name as viewed from another computer, and vice versa. Each APPC platform must define at least one local LU, which must be unique within the network. Since there are only up to 8 characters with which to create a unique LU name, this can be somewhat challenging in networks with many computers. Some possible naming conventions for LUs include: - Assigning consecutive LU names (alphabetically increasing) under central administration control. - Incorporating something that is already unique to each computer. Examples include: -- Serial number of the computer -- Person number of the user -- Unique userid of the user On some APPC platforms, you must predefine the list of partner LUs that the computer will be able to communicate with. Other platforms allow you to use any fully qualified LU name without having defined it beforehand. The APPC platform will then dynamically find that LU in the network. o What kind of connection should be made with the server computer. When the APING client program requests a connection with a partner LU, the APPC platform establishes what is called a session between the local LU and the partner LU. The simplest session that can be established occurs when the client computer and the server computer are directly connected with a single APPC link. The session goes directly from the client computer to the server computer. If your network is larger and more complex, the client computer may be connected to a network node computers rather than directly to the server computer. In this case, the session that is established may pass through other computers in the network. To add to the complexity, there may be different paths through the network. The network will always choose the best path through the network for your application. Since different applications have different needs, APPC provides a way for the application to specify the route characteristics that are best for that application. The application specifies a mode name which contains all the routing characteristics required by the application. The characteristics associated with a mode include: - Turnaround time How fast must data get through the network? - Throughput How much data can get through the network? - Cost Are you paying for physical connections between computers? Two modes which are commonly supplied with APPC platforms are #BATCH and #INTER. The definition for #BATCH specifies a path with good throughput characteristics. The definition for #INTER specifies a path with good turnaround time. If your platform does not supply a definition for these modes, you can either define them on your platform, or use some other mode that is already defined by specifying the mode name when you start the APING client program. o How to identify and start the correct program on the server computer. When the client computer establishes a connection with the server computer, the server computer must make that connection with a particular server program. To help the server computer identify the server program, a transaction program name is sent from the client computer. The server program is identified by this transaction program (TP) name. The TP name is a 1 to 64 byte string. Because the actual executable program names can be different on various computers, the TP name is used as a common identifier or an alias for the real program name. In many cases, the TP name and the real program name will be identical. On the client computer, the TP name is specified by the APING client program and is the first thing sent by the client APPC platform to the server APPC platform. The client computer does need to have a TP name definition configured. The server APPC platform then needs to know how to correlate the received TP name with an actual program. This is done through a TP definition, which tells the server APPC platform which program should be started and the application parameters and characteristics associated with the program. Some common things that can be configured are: - The name and location (e.g., subdirectory) of the server program - A list of users who can use the server program - Parameters that should be passed to the program when it is started +---------------------------------------------------------------------------+ | | | Platform Specific Configuration | | | +---------------------------------------------------------------------------+ The following steps have been described for each APPC platform that APING has been tested with (see the list above in the Configuration Guide for APING section). Each platform will have the following information: o General configuration tools - Where and how configuration changes are made - How to make your configuration changes take effect o Configuration changes common to client and server computers o Configuration changes specific to the client computer How to specify and identify where your server is and how to reach your server. o Configuration changes specific to the server computer How to specify which clients can use the server and what server program to start when the TP arrives. Each platform also requires data link control configuration information. In all of the examples, token ring data link control configuration will be shown. For information about configuring other data link controls, see the documentation for the specific platform. +---------------------------------------------------------------------------+ | | | Configuration for Networking Services/DOS | | | +---------------------------------------------------------------------------+ o General configuration tools - Where and how configuration changes are made All configuration changes for Networking Services/DOS are made in the Networking Services/DOS configuration file. To make changes to your configuration, you must edit the Networking Services/DOS configuration file according to the directions below. The default configuration file is named CONFIG.NSD and is usually in the \NSD subdirectory. You may use another file name, but you will have to specify that name explicitly when you use the NSD command (see below). - How to make your configuration changes active After you have edited your Networking Services/DOS configuration file, you should use the NSD command to start NSD and activate your configuration changes. If you are using the default configuration file, you should use: nsd start If you are using another Networking Services/DOS configuration file, you should use: nsd start FILENAME o Configuration changes common to client and server computers - Defining a local LU Include an "nsdn" statement in your Networking Services/DOS configuration file: nsdn NETWORK_NAME.CLIENT_LU The name specified by the "nsdn" entry must be unique throughout your network. - Defining a partner LU -- If you are directly connected to your partner computer, include "nsdc" and "trld" entries in your Networking Services/DOS configuration file. You must specify both the partner LU name and the token ring destination address of the partner computer. For example: nsdc lan trld SERVER_LU,400000000001 -- If you are connected to your partner computer through a network node, "nsdc," and "trld" entries in your Networking Services/DOS configuration file. For example: nsdc lan trld NN_LU,600000000002 In this example, we specify a physical connection to our network node, specifying the LU name of the network node (NN_LU) and the token ring destination address. We then specify that the LU name SERVER_LU can be reached through the network node NN_LU. In both cases, change the token ring destination address in the example to the address of the partner computer you are connecting to. - Defining a link to a partner computer or to the network node The definition of the link has already been done in the partner LU section above. - Defining a mode Since Networking Services/DOS has already defined the IBM supplied mode names in the supplied MODE.NSD file, including #INTER, no mode definitions on Networking Services/DOS are needed for APING. o Configuration changes specific to the client computer No special configuration is needed for Networking Services/DOS to configure the APING client. o Configuration changes specific to the server computer Consult your Networking Services/DOS documentation for information on how to run server programs in a DOS or Windows environment. +---------------------------------------------------------------------------+ | | | Configuration for Extended Services and Networking Services/2 (OS/2) | | | +---------------------------------------------------------------------------+ o General configuration tools - Where and how configuration changes are made To configure Extended Services and Networking Services/2 use either the Configuration Management panels or edit the Node Definitions File (NDF). Although the following examples show Node Definitions File commands, you can enter the same information on the Configuration Management panels. Your Node Definitions File file will have the same filename as your Communications Manager configuration file, but with a file extension of "NDF." - How to make your configuration changes active You must verify the configuration file after changes are made to the configuration. If you have edited the Node Definitions File, run APPNV from an OS/2 Command prompt with the /e option to verify and update your configuration. For example: appnv WRKBASE.NDF /e o Configuration changes common to client and server computers - Defining a local LU During the Extended Services and Networking Services/2 installation process, at least one local LU was configured. This is the LU that will be used when you run the APING client. When your computer is acting as a server, this is the LU name that should be configured on the client platform as the partner LU. You can find your local LU in the DEFINE_LOCAL_CP command In the following Node Definitions File excerpt: define_local_cp fq_cp_name(NETWORK_NAME.CLIENT_LU) cp_alias(mylu) node_id(x'50000') node_type(en); The local LU is NETWORK_NAME.CLIENT_LU. - Defining a partner LU Since both Extended Services and Networking Services/2 support APPN, you do not need to define partner LU names. When your computer is the client, you will simply need to specify the fully qualified name of your partner LU. This fully qualified name includes the network name and LU name concatenated with a period. To enable any partner to call you when your computer is a server, make sure your Node Definitions File contains the following: define_defaults implicit_inbound_plu_support(yes); An additional feature of defining partner LUs is that you can provide an alias for the actual partner LU name. For example, you could define "server" to be an alias for NETWORK_NAME.SERVER_LU. Alias are case sensitive; "SERVER" is a different alias than "server." If you choose to define partner LUs, either to provide an alias for use when running the APING client, or to restrict the names of partner clients that can contact you, use a "define_partner_lu" command as follows: define_partner_lu fq_partner_lu_name(NETWORK_NAME.SERVER_LU) partner_lu_alias(server); - Defining a link to a partner computer or to the network node -- To define a link directly to your partner, your Node Definitions File should contain a "define_link" command, define_logical_link link_name(link) fq_adjacent_cp_name(NETWORK_NAME.SERVER_LU) adjacent_node_type(len) dlc_name(ibmtrnet) adapter_number(0) destination_address(x'400000000001') cp_cp_session_support(no) activate_at_startup(no); -- To define a link to your network node, your Node Definitions File should contain a "define_link" command, define_logical_link link_name(link) adjacent_node_type(nn) dlc_name(ibmtrnet) adapter_number(0) destination_address(x'600000000002') cp_cp_session_support(yes) activate_at_startup(yes); Note that the CP name of the network node does not have to be specified on the "define_link" command. In both cases, change the destination address in the example to the address of the partner computer you are connecting to. In order to allow other computers to configure links to your computer, you will need to give them your local token ring address. To find out your own token ring address, look in the ACSLAN.LOG file in the \CMLIB subdirectory if you are using Networking Services/2 or the LANTRAN.LOG file in the \IBMCOM subdirectory if you are using Extended Services. Your token ring address appears in a line similar to the following: Adapter 0 is using node address 400000000000. o Configuration changes specific to the client computer No special configuration is needed for Extended Services or Networking Services/2 to configure the APING client. o Configuration changes specific to the server computer - Defining the TP Configure the APINGD program as follows. Make sure the "filespec" specifies the directory where the APINGD.EXE program resides. define_tp tp_name(APINGD) filespec(C:\SAMPLES\APING\APINGD.EXE) tp_operation(nonqueued_am_started) program_type(vio_windowable); The "tp_operation" field indicates that a new copy of the APINGD.EXE program should be started for every new client. The "program_type" field indicates that the program should be run in an OS/2 Window. Note that TP names are case sensitive. The APINGD must be typed in all upper case. +---------------------------------------------------------------------------+ | | | Configuration for VM | | | +---------------------------------------------------------------------------+ +--- WARNING ---------------------------------------------------------------+ | | | The configuration instructions for VM have not been fully tested. If you | | have problems, please contact the author (indicated at the top of this | | file). | | | +---------------------------------------------------------------------------+ o General configuration tools - Where and how configuration changes are made There are four places where configuration changes are required for VM: 1. The CP directory entry must be changed to include definition of the server. 2. The client must define a local directory entry that describes the path that VTAM uses to find the server. 3. The APPC VTAM Service Machine (AVS) must be configured to know how to map requests between VTAM and local resources. 4. VTAM must be configured so that it knows about the APPC gateway as well as any remote clients or servers. More detailed information on the configuration can be found in CONNECTIVITY PLANNING, ADMINISTRATION, AND OPERATION, SC24-5448. - How to make configuration changes active Once CP directory entries are put online (DIRMAINT is typically used for this), the server is ready. After adding directory entries to the local directory the SET COMDIR command must be issued to activate the changes. The major nodes of VTAM affected by the changes must be restarted for VTAM changes to become active. AVS can either be restarted, or commands can be issued to the virtual machine to make any new gateways known. o Configuration common to client and server computers - Define AVS Gateway LU to VTAM The AVS gateway is a gateway between local resources (programs running in virtual machines) and the VTAM network. To communicate through VTAM it acts as a VTAM application. It therefore must be defined in a VTAM application major node. An example is shown below: APLAVS VBUILD TYPE=APPL SERVER_LU APPL APPC=YES, X AUTH=(ACQ), X ACBNAME=SERVER_LU, X AUTOSES=0, X AUTHEXIT=YES, X MODETAB=APPCMODE, X DLOGMOD=#INTER, X PARSESS=YES, X SECACPT=NONE This definition uses a logmode name of #INTER. This must be the mode used on the bind from the client, if it is in the VTAM network. Logmode #INTER must also be assembled and link-edited into a simulated partitioned data set (PDS) accessible by VTAM. In the example below it would be in member APPCMODE. The PDS used is typically VTAMUSER. The following sample mode table contains definitions for typical APPC modes. APPCMODE MODETAB ********************************************************************** * LOGMODE TABLE ENTRY FOR RESOURCES CAPABLE OF ACTING * * AS LU 6.2 DEVICES @R495812 @KFC* ********************************************************************** SNASVCMG MODEENT LOGMODE=SNASVCMG,FMPROF=X'13',TSPROF=X'07', * PRIPROT=X'B0',SECPROT=X'B0',COMPROT=X'D0B1', * RUSIZES=X'8686',ENCR=B'0000',SSNDPAC=7, *@KFC* * PSERVIC=X'060200000000000000000300', *@R495812* * SRCVPAC=7,PSNDPAC=7,TYPE=0 *@KFA* TITLE '#BATCH' *@KFA* *********************************************************************** * * * LOGMODE TABLE FOR BATCH SESSIONS ON RESOURCES CAPABLE * * OF ACTING AS LU 6.2 DEVICES * * @KFA* *********************************************************************** #BATCH MODEENT LOGMODE=#BATCH, *@KFA* * ENCR=B'0000',SSNDPAC=3, *@KFA* * SRCVPAC=3,PSNDPAC=3 *@KFA* TITLE '#INTER' *@KFA* *********************************************************************** * * * LOGMODE TABLE FOR INTERACTIVE SESSIONS ON RESOURCES * * CAPABLE OF ACTING AS LU 6.2 DEVICES * * @KFA* *********************************************************************** #INTER MODEENT LOGMODE=#INTER, *@KFA* * ENCR=B'0000',SSNDPAC=7, *@KFA* * SRCVPAC=7,PSNDPAC=7 *@KFA* TITLE '#BATCHSC' *@KFA* *********************************************************************** * * * LOGMODE TABLE FOR BATCH SESSIONS REQUIRING SECURE * * TRANSPORT ON RESOURCES CAPABLE OF ACTING AS LU 6.2 * * DEVICES * * @KFA* *********************************************************************** #BATCHSC MODEENT LOGMODE=#BATCHSC, *@KFA* * ENCR=B'0000',SSNDPAC=3, *@KFA* * SRCVPAC=3,PSNDPAC=3 *@KFA* TITLE '#INTERSC' *@KFA* *********************************************************************** * * * LOGMODE TABLE FOR INTERACTIVE SESSIONS REQUIRING * * SECURE TRANSPORT ON RESOURCES CAPABLE OF ACTING AS * * LU 6.2 DEVICES * * @KFA* *********************************************************************** #INTERSC MODEENT LOGMODE=#INTERSC, *@KFA* * ENCR=B'0000',SSNDPAC=7, *@KFA* * SRCVPAC=7,PSNDPAC=7 *@KFA* TITLE 'CPSVCMG' *@KFA* *********************************************************************** * * * LOGMODE TABLE FOR CP-CP SESSIONS ON RESOURCES CAPABLE * * OF ACTING AS LU 6.2 DEVICES * * @KFA* *********************************************************************** CPSVCMG MODEENT LOGMODE=CPSCVMG, *@KFA* * RUSIZES=X'8686',ENCR=B'0000', *@KFA* * SSNDPAC=7,SRCVPAC=7,PSNDPAC=7 *@KFA* MODEEND END - Define AVS Gateway to AVS Service Machine The gateway defined to VTAM must also be defined for the AVS virtual machine. This can be done in the AGWPROF GCS, which is the profile information for the AVS service machine. An example is shown below: /*********************************/ /* */ /* SAMPLE AGWPROF GCS FOR AVS */ /* */ /*********************************/ Trace O 'AGW ACTIVATE GATEWAY SERVER_LU PRIVATE USERID VMSERVER' 'AGW CNOS SERVER_LU CLIENT_LU #INTER 2 0 2' The above example activates a private gateway called SERVER_LU, which is used exclusively by a server running under userid VMSERVER. It also issues a CNOS (change number of sessions) to establish two sessions with a device in the VTAM subarea network called CLIENT_LU. o Configuration specific to the client computer The user must define a directory that tells APPC how to find the target server, and other parameters of the conversation. These are kept in a UCOMDIR NAMES file, similar to the NAMES file used by such things as the NOTE exec. An example is shown below: :nick.SERVER :luname.SERVER_LU CLIENT_LU :tpn.APINGD :modename.#INTER :security.NONE This tells APPC/VM that a resource called SERVER can be located in the VTAM subarea network by using gateway SERVER_LU to establish a session with CLIENT_LU using logmode #INTER. The transaction program (TPN) to start on that computer is called APINGD. Once this is added to the directory, the changes are activated by issuing: SET COMDIR RELOAD In addition, VTAM must be able to find the partner LU SERVER_LU. In VTAM V3R4, a session management exit may be defined to do this function. Based on the LU name, the exit can be customized to determine which Adjacent Link Station (this would typically be a PU2.1) to send the bind to. For pre-V3R4 VTAMs the LU must be defined. An example of a definition for a Switched Major Node is given below: PCSWNODE VBUILD TYPE=SWNET,MAXGRP=10,MAXNO=10 SERVER_LUP PU ADDR=04,ISTATUS=ACTIVE,PACING=7, X MAXDATA=2044,IDBLK=05D,IDNUM=00100, X MAXOUT=7,PASSLIM=7,MAXPATH=1, X PUTYPE=2,LANSW=YES, X MODETAB=AGWTAB,DLOGMOD=#INTER X SERVER_LU LU LOCADDR=0,ISTATUS=ACTIVE o Configuration specific to the server computer In the AVS virtual machine definition, VMSERVER was configured as a private server, and an LU definition in VTAM (SERVER_LU) assigned to it. The following commands must be included in VMSERVER PROFILE EXEC to configure it to run as a private resource server: 'SET SERVER ON' 'SET FULLSCREEN OFF' 'SET AUTOREAD OFF' The following must be added to the $SERVER$ NAMES file on the VMSERVER userid: :nick.APINGD :list.* :module.APINGD +---------------------------------------------------------------------------+ | | | Configuration for MVS. | | | +---------------------------------------------------------------------------+ +--- WARNING ---------------------------------------------------------------+ | | | The configuration instructions for MVS have not been fully tested. If | | you have problems, please contact the author (indicated at the top of | | this file). | | | +---------------------------------------------------------------------------+ o Where and how configuration changes are made APPC/MVS configuration is detailed in Planning: APPC Management(GC28-1110). In general it involves defining parameters for two subsystems, APPC and ASCH. They run in separate address spaces. The APPC address space handles the actual communications, while ASCH is a scheduler that initiates transaction programs based on receipt of incoming attaches. Beyond these two address spaces, some configuration is required in VTAM. MVS/ESA 4.2 or later is required for APPC/MVS. o The APPC/MVS Address Spaces Both APPC and ASCH have parmlib members that contain configuration information for the respective address spaces. Samples are shipped with MVS/ESA 4.2 or higher in SYS1.SAMPLIB. These samples can be modified and copied into SYS1.PARMLIB to provide the parameters necessary to start the respective subsystems. Their names in SYS1.SAMPLIB are APPCPMXX and ASCHPMXX. The "XX" must be changed to a numeric value when the members are placed in SYS1.PARMLIB. Below is a sample SYS1.PARMLIB(APPCPM00), which is the default used at startup. /***PROPRIETARY_STATEMENT********************************************/ /* */ /* */ /* LICENSED MATERIALS - PROPERTY OF IBM */ /* THIS MACRO IS "RESTRICTED MATERIALS OF IBM" */ /* 5695-047 (C) COPYRIGHT IBM CORP. 1990 */ /* SEE COPYRIGHT INSTRUCTIONS */ /* */ /* STATUS= HBB4420 */ /* */ /***END_OF_PROPRIETARY_STATEMENT*************************************/ /********************************************************************/ /* This is a sample APPCPM00 member of SYS1.PARMLIB. */ /* */ /* APPCPM00 parmlib members contain startup, default and */ /* customization values for APPC/MVS. They also contain */ /* information indicating the correspondence between */ /* logical unit(LU) names and transaction schedulers. */ /* */ /* This member illustrates the syntax of the LUADD, LUDEL, */ /* LMADD, LMDEL and SIDEINFO statement types. */ /* */ /* NOTE: */ /* */ /* This SAMPLIB member is only an example. The value */ /* represented on each statement is not necessarily an */ /* IBM-recommended value. */ /* Installations may use this member as a sample, and */ /* modify it according to their needs. */ /* */ /* DO NOT COPY AND USE THIS SAMPLE WITHOUT PROVIDING THE */ /* NECESSARY SUPPORT FOR THE VALUES IT NAMES. */ /* */ /********************************************************************/ /********************************************************************/ /* */ /* Define a local LU with the name TOMVSAP to the APPC/MVS */ /* configuration. */ /* */ /* Note: */ /* */ /* 1. The VSAM data set specified on the TPDATA keyword */ /* must be already defined to the system, otherwise an */ /* error message will be issued. */ /* */ /* 2. If this LU is intended to handle network traffic, */ /* then the LU name MVSLU01 must correspond to the */ /* ACBNAME operand of an application definition (APPL) */ /* statement in the SYS1.VTAMLST system library and */ /* the ACBNAME & APPL name must match. */ /* */ /********************************************************************/ LUADD ACBNAME(TOMVSAP) /* Add local LU MVSLU01 to the */ /* APPC/MVS configuration */ SCHED(ASCH) /* Specify that the APPC/MVS */ /* transaction scheduler is associated */ /* with this LU name */ BASE /* Designate this LU as the base LU */ TPDATA(SYS1.APPCTP) /* Specify that VSAM data set */ /* SYS1.APPCTP is the permanent */ /* repository for the TP profiles */ /* for this LU */ TPLEVEL(USER) /* Specify the search order for TP */ /* profiles as : */ /* 1. TP profiles associated with */ /* a specific user */ /* 2. TP profiles associated with */ /* a group of users */ /* 3. TP profiles associated with */ /* all users of the LU name */ /********************************************************************/ /* */ /* Specify that Side information is to be kept in VSAM */ /* data set SYS1.APPCSI. */ /* */ /* Note: */ /* */ /* 1. If the SIDEINFO statement is specified with no operands */ /* then the default will be: */ /* o DATASET(SYS1.APPCSI) */ /* */ /* 2. The VSAM data set specified on the DATASET keyword */ /* must be already defined to the system, otherwise an */ /* error message will be issued. */ /* */ /********************************************************************/ SIDEINFO DATASET(SYS1.APPCSI) /* Specify that VSAM data set */ /* SYS1.APPCSI is the permanent */ /* repository for the side */ /* information */ Below is a sample ASCHPM00 parmlib member. /*01* PROPRIETARY STATEMENT= */ /***PROPRIETARY_STATEMENT********************************************/ /* */ /* */ /* LICENSED MATERIALS - PROPERTY OF IBM */ /* THIS MACRO IS "RESTRICTED MATERIALS OF IBM" */ /* 5695-047 (C) COPYRIGHT IBM CORP. 1990 */ /* SEE COPYRIGHT INSTRUCTIONS */ /* */ /* STATUS= HBB4420 */ /* */ /***END_OF_PROPRIETARY_STATEMENT*************************************/ /********************************************************************/ /* This is a sample ASCHPM00 member of SYS1.PARMLIB. */ /* */ /* ASCHPMxx parmlib members contain startup, default and */ /* customization values for the APPC/MVS transaction scheduler. */ /* These parmlib members define classes of transaction */ /* initiators in which a transaction program can run. */ /* */ /* This member illustrates the syntax of the CLASSADD, */ /* OPTIONS and TPDEFAULT statement types. */ /* */ /* NOTE: */ /* */ /* This SAMPLIB member is only an example. The value */ /* represented on each statement is not necessarily an */ /* IBM-recommended value. */ /* Installations may use this member as a sample, and */ /* modify it according to their needs. */ /* */ /* DO NOT COPY AND USE THIS SAMPLE WITHOUT PROVIDING THE */ /* NECESSARY SUPPORT FOR THE VALUES IT NAMES. */ /* */ /********************************************************************/ /********************************************************************/ /* */ /* Define a class of transaction initiators to be added to */ /* the APPC/MVS transaction scheduler configuration. */ /* The class has the following characteristics: */ /* o Class name - FAST */ /* o Maximum number of transaction initiators allowed - 10 */ /* o Minimum number of transaction initiators to be */ /* brought up - 2 */ /* o Response time goal - 0.02 seconds */ /* o Maximum size of the job log for TPs - 500 messages */ /* */ /********************************************************************/ CLASSADD CLASSNAME(FAST) /* Specify the name of the class to be */ /* added */ MAX(10) /* Specify that the maximum number */ /* of transaction initiators allowed */ /* for this class is 10 */ MIN(2) /* Specify that the minimum number */ /* of transaction initiators to be */ /* brought up for this class is 2 */ RESPGOAL(.02) /* Specify that the response time */ /* goal for transaction programs */ /* executing within this class is 0.02 */ /* seconds */ MSGLIMIT(500) /* Specify that the maximum size of */ /* the job logs for TPs is 500 */ /* messages */ /********************************************************************/ /* */ /* Define a class of transaction initiators to be added to */ /* the APPC/MVS transaction scheduler configuration. */ /* The class has the following characteristics: */ /* o Class name - SLOW */ /* o Maximum number of transaction initiators allowed - 1 */ /* o Minimum number of transaction initiators to be */ /* brought up - 0 */ /* o Response time goal - 1 second */ /* o Maximum size of the job log for TPs - 500 messages */ /* */ /* Note: */ /* */ /* 1. Defaults are used if keywords are omitted from a */ /* CLASSADD statement except for the CLASSNAME. */ /* */ /* 2. The following defaults will be taken for this entry: */ /* o MAX(1) */ /* o MIN(0) */ /* o RESPGOAL(1) */ /* o MSGLIMIT(500) */ /* */ /********************************************************************/ CLASSADD CLASSNAME(SLOW) /* Specify the name of the class to be */ /* added */ /********************************************************************/ /* */ /* Define the APPC/MVS transaction scheduler configuration */ /* default class in which to run transaction programs when a */ /* classname is not specified in the TP profile, and define */ /* the subsystem to which all newly created APPC/MVS */ /* transaction initiators are assigned. */ /* */ /* Note: */ /* */ /* 1. There is no default for the DEFAULT keyword. */ /* */ /* 2. The default SUBSYS(Primary subsystem name) will only */ /* apply when there is no prior SUBSYS defined to the */ /* APPC/MVS transaction scheduler configuration. */ /* */ /********************************************************************/ OPTIONS DEFAULT(SLOW) /* Specify the default class */ SUBSYS(JES2) /* Specify the name of a subsystem */ Note that both SYS1.APPCTP and SYS1.APPCSI must be defined prior to starting APPC and ASCH. Below are sample jobs to do these tasks: //ATBTP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) /*JOBPARM LINES=9999,TIME=1440 //*************************************************************/ //* */ //* THIS IS A SAMPLE DEFINITION FOR A VSAM KEY SEQUENCED */ //* DATA SET (KSDS) TO CONTAIN APPC TP PROFILES. YOU CAN */ //* USE THIS SAMPLE OR MODIFY IT. */ //* */ //* A TP PROFILE ENTRY CONTAINS IDENTIFICATION, SECURITY, */ //* AND SCHEDULING INFORMATION FOR A TP THAT RESPONDS TO */ //* AN INBOUND ALLOCATE REQUEST. */ //* */ //* */ //* SHAREOPTIONS(3 3) - */ //* */ //* MUST BE (3 3) BECAUSE THE APPC SUBSYSTEM REFERENCES */ //* THIS KSDS IN SUCH A WAY THAT IT MUST BE FULLY */ //* SHARED. */ //* */ //* RECORDSIZE(3824 7024) - */ //* */ //* THIS IS THE AVERAGE AND MAXIMUM RECORD SIZE. */ //* */ //* AVERAGE CALCULATION: */ //* */ //* TP PROFILE KEY 112 BYTES */ //* NON JCL DATA (maximum possible) 512 BYTES */ //* JCL (40 LINE OF 80 BYTES) 3200 BYTES */ //* ------------ ------------- */ //* TOTAL 3824 BYTES */ //* */ //* MAXIMUM CALCULATION: */ //* */ //* TP PROFILE KEY 112 BYTES */ //* NON JCL DATA (maximum possible) 512 BYTES */ //* JCL (80 LINE OF 80 BYTES) 6400 BYTES */ //* ------------ ------------- */ //* TOTAL 7024 BYTES */ //* */ //* */ //* THIS KSDS IS DESIGNED TO HOLD 300 TP PROFILES */ //* BUT CAN EXPAND TO HOLD AN ADDITIONAL 150. */ //* */ //* CHANGES: */ //* */ //* - REPLACE CNMSTC WITH THE NAME OF YOUR VOLUME. */ //* - REPLACE, IF NECESSARY, SYS1.APPCTP WITH THE NAME */ //* OF YOUR TP PROFILE DATASET. */ //* - REPLACE, IF NECESSARY, THE RECORDS VALUES WITH THE */ //* NUMBER OF TP PROFILES THE KSDS IS DESIGNED TO HOLD */ //* AND THE EXPANSION NUMBER. */ //* */ //*************************************************************/ //TPSAMPLE EXEC PGM=IDCAMS //CNMSTC DD DISP=OLD,UNIT=3380,VOL=SER=CNMSTC //SYSPRINT DD SYSOUT=* //SYSABEND DD SYSOUT=* //AMSDUMP DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER (NAME(SYS1.APPCTP) - VOLUMES(CNMSTC) - INDEXED REUSE - SHAREOPTIONS(3 3) - RECORDSIZE(3824 7024) - KEYS(112 0) - RECORDS(300 150)) - DATA - (NAME(SYS1.APPCTP.DATA)) - INDEX - (NAME(SYS1.APPCTP.INDEX)) /* //ATBSI02 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) /*JOBPARM LINES=9999,TIME=1440 //*************************************************************/ //* */ //* THIS IS A SAMPLE DEFINITION FOR A VSAM KEY SEQUENCED */ //* DATA SET (KSDS) TO CONTAIN APPC SIDE INFORMATION. */ //* YOU CAN USE THIS SAMPLE OR MODIFY IT. */ //* */ //* A SIDE INFORMATION ENTRY CONTAINS THE TRANSLATION OF A */ //* SYMBOLIC DESTINATION NAME THAT IS USED TO INITIATE AN */ //* APPC CONVERSATION. THE SIDE INFORMATION ENTRY CONSISTS */ //* OF: */ //* */ //* SI KEY 112 BYTES */ //* SI DATA 136 BYTES */ //* --------- ----------- */ //* TOTAL 248 BYTES */ //* */ //* THIS KSDS IS DESIGNED TO HOLD 50 SIDE INFORMATION */ //* ENTRIES BUT CAN EXPAND TO HOLD AN ADDITIONAL 25. */ //* */ //* CHANGES: */ //* */ //* - REPLACE CNMSTC WITH THE NAME OF YOUR VOLUME. */ //* - REPLACE, IF NECESSARY, SYS1.APPCSI WITH THE NAME OF */ //* YOUR SIDE INFORMATION REPOSITORY. */ //* - REPLACE, IF NECESSARY, THE RECORDS VALUES WITH THE */ //* NUMBER OF ENTRIES THE KSDS IS DESIGNED TO HOLD */ //* AND THE EXPANSION NUMBER. */ //* */ //*************************************************************/ //SISAMPLE EXEC PGM=IDCAMS //CNMSTC DD DISP=OLD,UNIT=3380,VOL=SER=CNMSTC //SYSPRINT DD SYSOUT=* //SYSABEND DD SYSOUT=* //AMSDUMP DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER (NAME(SYS1.APPCSI) - VOLUME(CNMSTC) - INDEXED REUSE - SHAREOPTIONS(3 3) - RECORDSIZE(248 248) - KEYS(112 0) - RECORDS(50 25)) - DATA - (NAME(SYS1.APPCSI.DATA)) - INDEX - (NAME(SYS1.APPCSI.INDEX)) For APINGD to be scheduled by ASCH, a transaction program (TP) profile must be created. This information is loaded into the TP profile VSAM dataset. Below is a sample job to do this: //ATBTP01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) //************************************************************* //* Change YOURUSER to your own userid //* //STEP EXEC PGM=ATBSDFMU //SYSPRINT DD SYSOUT=* //SYSSDLIB DD DSN=SYS1.APPCTP,DISP=SHR //SYSSDOUT DD SYSOUT=* //SYSIN DD DATA,DLM=XX TPADD TPNAME(APINGD) ACTIVE(YES) TPSCHED_DELIMITER(##) TAILOR_SYSOUT(NO) TAILOR_ACCOUNT(NO) CLASS(FAST) TPSCHED_TYPE(STANDARD) JCL_DELIMITER(END_OF_JCL) //APINGD JOB MSGLEVEL=(1,1),MSGCLASS=A //IKJACCNT EXEC PGM=IKJEFT01,PARM='CALL ''YOURUSER.LOADLIB(APINGD)''' //SYSUADS DD DISP=SHR,DSN=SYS1.UADS //SYSLBC DD DISP=SHR,DSN=SYS1.BRODCAST //STEPLIB DD DSN=YOURUSER.LOADLIB,DISP=SHR // DD DSN=EDC.V2R1M0.SEDCLINK,DISP=SHR // DD DSN=PLI.V2R3M0.SIBMLINK,DISP=SHR // DD DSN=ISP.V3R2M0.ISPLOAD,DISP=SHR //SYSTSPRT DD SYSOUT=A,FREE=CLOSE //SYSTSIN DD DUMMY //SYSPRINT DD SYSOUT=A,FREE=CLOSE END_OF_JCL KEEP_MESSAGE_LOG(ERROR) ## XX /* In the above, the load module for APINGD is assumed to reside in YOURUSER.LOADLIB. Also, note the CLASS is FAST, and those parameters were defined in the ASCHPM00 member above. If APING is to use CPI-C side information, the side information must be loaded into the side information VSAM data set, SYS1.APPCSI. Below is a sample job to perform this function: //ATBSI01 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1) //************************************************************* //STEP EXEC PGM=ATBSDFMU //SYSPRINT DD SYSOUT=* //SYSSDLIB DD DSN=SYS1.APPCSI,DISP=SHR //SYSSDOUT DD SYSOUT=* //SYSIN DD * SIADD DESTNAME(IBMRTP) TPNAME(APINGD) MODENAME(#INTER) PARTNER_LU(SERVER_LU) /* In the above example, the side information name IBMRTP will designate the partner TP APINGD at partner LU SERVER_LU using mode #INTER. In order to start the two subsystems, the commands: START APPC,SUB=MSTR START ASCH,SUB=MSTR must be issued at the console. These commands use the SYS1.PROCLIB members APPC and ASCH, shipped with MVS/ESA 4.2 or higher. o VTAM The application name for the APPC/MVS LU must be defined. The following example shows this. While this shows only one LU definition, it is possible for APPC/MVS to have multiple LU definitions that can be used for different purposes. AB7APPLS VBUILD TYPE=APPL TOMVSAP APPL ACBNAME=TOMVSAP,APPC=YES,AUTOSES=5,DDRAINL=NALLOW, * DMINWNL=3,DMINWNR=6,DRESPL=NALLOW,DSESLIM=9,EAS=509, * MODETAB=APPCMODE,SECACPT=CONV,VPACING=2,VERIFY=NONE, * SRBEXIT=YES,DLOGMOD=#INTER Note that the LU name (TOMVSAP) matches the name defined in the PARMLIB member APPCPM00. The default mode name is #INTER, which is included in mode table APPCMODE. #INTER is an architected mode name. In general, mode names used should be from the set of architected ones. Below is a mode table containing these architected modes. APPCMODE MODETAB ********************************************************************** * LOGMODE TABLE ENTRY FOR RESOURCES CAPABLE OF ACTING * * AS LU 6.2 DEVICES @R495812 @KFC* ********************************************************************** SNASVCMG MODEENT LOGMODE=SNASVCMG,FMPROF=X'13',TSPROF=X'07', * PRIPROT=X'B0',SECPROT=X'B0',COMPROT=X'D0B1', * RUSIZES=X'8686',ENCR=B'0000',SSNDPAC=7, *@KFC* * PSERVIC=X'060200000000000000000300', *@R495812* * SRCVPAC=7,PSNDPAC=7,TYPE=0 *@KFA* TITLE '#BATCH' *@KFA* *********************************************************************** * * * LOGMODE TABLE FOR BATCH SESSIONS ON RESOURCES CAPABLE * * OF ACTING AS LU 6.2 DEVICES * * @KFA* *********************************************************************** #BATCH MODEENT LOGMODE=#BATCH, *@KFA* * ENCR=B'0000',SSNDPAC=3, *@KFA* * SRCVPAC=3,PSNDPAC=3 *@KFA* TITLE '#INTER' *@KFA* *********************************************************************** * * * LOGMODE TABLE FOR INTERACTIVE SESSIONS ON RESOURCES * * CAPABLE OF ACTING AS LU 6.2 DEVICES * * @KFA* *********************************************************************** #INTER MODEENT LOGMODE=#INTER, *@KFA* * ENCR=B'0000',SSNDPAC=7, *@KFA* * SRCVPAC=7,PSNDPAC=7 *@KFA* TITLE '#BATCHSC' *@KFA* *********************************************************************** * * * LOGMODE TABLE FOR BATCH SESSIONS REQUIRING SECURE * * TRANSPORT ON RESOURCES CAPABLE OF ACTING AS LU 6.2 * * DEVICES * * @KFA* *********************************************************************** #BATCHSC MODEENT LOGMODE=#BATCHSC, *@KFA* * ENCR=B'0000',SSNDPAC=3, *@KFA* * SRCVPAC=3,PSNDPAC=3 *@KFA* TITLE '#INTERSC' *@KFA* *********************************************************************** * * * LOGMODE TABLE FOR INTERACTIVE SESSIONS REQUIRING * * SECURE TRANSPORT ON RESOURCES CAPABLE OF ACTING AS * * LU 6.2 DEVICES * * @KFA* *********************************************************************** #INTERSC MODEENT LOGMODE=#INTERSC, *@KFA* * ENCR=B'0000',SSNDPAC=7, *@KFA* * SRCVPAC=7,PSNDPAC=7 *@KFA* TITLE 'CPSVCMG' *@KFA* *********************************************************************** * * * LOGMODE TABLE FOR CP-CP SESSIONS ON RESOURCES CAPABLE * * OF ACTING AS LU 6.2 DEVICES * * @KFA* *********************************************************************** CPSVCMG MODEENT LOGMODE=CPSCVMG, *@KFA* * RUSIZES=X'8686',ENCR=B'0000', *@KFA* * SSNDPAC=7,SRCVPAC=7,PSNDPAC=7 *@KFA* MODEEND END This table should be assembled and placed in a dataset defined to STEPLIB in the VTAM start procedure. VTAM must also be able to find the partner LU SERVER_LU. In VTAM V3R4, a session management exit may be defined to do this function. Based on the LU name, the exit can be customized to determine which Adjacent Link Station (this would typically be a PU2.1) to send the bind to. For pre-V3R4 VTAMs the LU must be defined. An example of a definition for a Switched Major Node is given below: PCSWNODE VBUILD TYPE=SWNET,MAXGRP=10,MAXNO=10 SERVER_LUP PU ADDR=04,ISTATUS=ACTIVE,PACING=7, X MAXDATA=2044,IDBLK=05D,IDNUM=00100, X MAXOUT=7,PASSLIM=7,MAXPATH=1, X PUTYPE=2,LANSW=YES, X MODETAB=AGWTAB,DLOGMOD=#INTER X SERVER_LU LU LOCADDR=0,ISTATUS=ACTIVE +---------------------------------------------------------------------------+ | | | Configuration for AS/400 | | | +---------------------------------------------------------------------------+ o General configuration tools - Where and how configuration changes are made AS/400 configuration is performed through a series of menu driven panels. You can access these panels either by proceeding through a series of menu choices, or by entering the command name directly. - How to make your configuration changes active Unless specifically noted, all configuration changes are active and usable as soon as they are entered. o Configuration changes common to client and server computers - Defining a local LU During the AS/400 installation process, at least one local LU was configured. This is the LU that will be used when you run the APING client. When your computer is acting as a server, this is the LU name that should be configured on the client platform as the partner LU. You can find your local LU on the Display Network Attributes panel. You can find this panel through the following sequence: define_local_cp fq_cp_name(NETWORK_NAME.CLIENT_LU) 7. Define or change the system 1. Configuration 4. Network management 1. Display network attributes You will see a panel similar to the following: Display Network Attributes System: CLIENT_LU Current system name . . . . . . . . . . . . . . : CLIENT_LU Pending system name . . . . . . . . . . . . . : Local network ID . . . . . . . . . . . . . . . . : NETWORK_NAME Local control point name . . . . . . . . . . . . : CLIENT_LU Default local location . . . . . . . . . . . . . : CLIENT_LU Default mode . . . . . . . . . . . . . . . . . . : BLANK APPN node type . . . . . . . . . . . . . . . . . : *NETNODE Maximum number of intermediate sessions . . . . : 200 Route addition resistance . . . . . . . . . . . : 128 Server network ID/control point name . . . . . . : The local LU is NETWORK_NAME.CLIENT_LU. - Defining a partner LU and Defining a link to a partner computer or to the network node On the AS/400, you can define your partner LU name and a logical link from the same configuration panel. A controller description is used to describe all the characteristics of an adjacent computer. You can access controller descriptions through the CRTCTLAPPC or CHGCTLAPPC commands (Create/Change Controller Description, APPC). The following example shows only the fields of the controller description that need to be changed. You can allow the other fields to use the defaults. CRTCTLAPPC Controller Description > SERVER_LU Link type > *LAN Online at IPL > *YES APPN-capable > *YES Switched line list > TRLAN Remote network identifier > NETWORK_NAME Remote control point > SERVER_LU LAN remote adapter address > 400000000001 APPN CP session support > *YES APPN node type > *ENDNODE APPN transmission group number > *CALC This example has used a token ring line description named TRLAN. To work with these line descriptions, use CRTLINTRN or CHGLINTRN. To use other DLC types, use CRTLINSDLC, CRTLINX25, CHGLINSDLC, CHGLINX25). o Configuration changes specific to the client computer No special configuration is needed for AS/400 to configure the APING client. o Configuration changes specific to the server computer - Defining the TP To configure the server side for AS/400, all you have to do is change the User Library List. The library where the APINGD program resides should be added to the list. To access the User Library List: -- Run the WRKSYSVAL command. -- Page down until you find the QUSRLIBL system value, select 2 for change. -- Add the library (usually APING) to the list. +---------------------------------------------------------------------------+ | | | Configuration for AIX SNA Services | | | +---------------------------------------------------------------------------+ o General configuration tools - Where and how configuration changes are made Configuration for AIX SNA Services can be done through either SMIT configuration panels, or importing ascii configuration files. The examples shown below will be excerpts from an ascii configuration file. You can either import these excerpts, or use them as a guide while configuring using SMIT. - How to make your configuration changes active The proper sequence of commands to change your configuration and make the changes active is: stopsrc -s sna importsna -l appc.pro startsrc -s sna o Configuration changes common to client and server computers - Defining a local LU The definition of a local LU involves defining a control point and a local LU. The control point definition should be: CLIENT_LU_CONTROL POINT: type = CONTROLPOINT profile_name = LOCALCP xid_node_id = 07100000 network_name = NETWORK_NAME cp_name = CLIENT_LU Where NETWORK_NAME and CLIENT_LU should be changed for your environment. The local LU definition should be: CLIENT_LU_LOCAL LU: type = LOCALLU profile_name = LOCALLU local_lu_name = CLIENT_LU network_name = NETWORK_NAME lu_type = lu6.2 independent_lu = yes cp_sessions = no tpn_list_name = LOCALTPS local_lu_address = 1 sscp_id = * number_of_rows = 24 number_of_columns = 80 - Defining a partner LU and Defining a link to a partner computer or to the network node The definition of a partner will require a number of steps: 1. Define the physical interface This tells AIX SNA Services about the physical interface characteristics. For token ring, this can be done with: LOCAL_TOKEN RING LOGICAL: type = TOKENRINGLOGICAL profile_name = LOCALLL transmit_window_count = 10 dynamic_window_increment = 1 retransmit_count = 8 receive_window_count = 127 ring_access_priority = 0 inactivity_timeout = 75 drop_link_on_inactivity = yes response_timeout = 2 acknowledgement_timeout = 1 force_disconnect_timeout = 120 link_trace = no trace_entry_size = long logical_link_type = token_ring maximum_i_field = system_defined maximum_i_field_size = 30729 physical_link_type = token_ring LOCAL_TOKEN RING PHYSICAL: type = TOKENRINGPHYSICAL profile_name = LOCALPL device_name = tok0 local_link_name = NONE local_sap_address = 04 physical_link_type = token_ring maximum_number_of_logical_links = 32 2. Define attachment profiles These profiles specify the address and link characteristics for connecting to your partner at the link level. There are attachment profiles for incoming link activations (listen) and outgoing link activations (call). In order to allow either side to activate the link, you must define both a listen and a call attachment profile. The listen attachment must be started before the partner tries to activate the link by executing a command: startsrc -t attachment -o LISTEN_PARTNER The listen attachment is defined as follows: LISTEN_ATTACHMENT: type = ATTACHMENT profile_name = LISTEN control_point_profile_name = LOCALCP logical_link_profile_name = LOCALLL physical_link_profile_name = LOCALPL logical_link_type = token_ring stop_attachment_on_inactivity = no station_type = secondary physical_link_type = token_ring remote_secondary_station_address = 1 smart_modem_command_sequence = length_of_command_sequence = 0 call_type = listen x25_level = 1984 listen_name = IBMQLLC autolisten = yes timeout_value = 0 remote_link_name_ethernet = remote_link_name_token_ring = remote_link_address = selection_sequence = length_of_selection_sequence = 0 network_type = switched access_routing = link_address remote_sap_address = 04 remote_sap_address_range_lower = 04 remote_sap_address_range_upper = EC virtual_circuit_type = permanent remote_station_X.25_address = optional_X.25_facilities = no logical_channel_number_of_PVC = 1 reverse_charging = no rpoa = no default_packet_size = yes default_window_size = yes default_throughput_class = yes closed_user_group = no closed_user_group_outgoing = no network_user_id = no network_user_id_name = data_network_identification_code = packet_size_for_received_data = 128 packet_size_for_transmit_data = 128 window_size_for_received_data = 4 window_size_for_transmit_data = 4 throughput_class_for_received_data = 1200 throughput_class_for_transmit_data = 1200 index_to_selected_closed_user_group = 0 lu_address_registration = no lu_address_registration_name = LDEFAULT The call attachment is defined as follows: CALL_ATTACHMENT: type = ATTACHMENT profile_name = CALL control_point_profile_name = LOCALCP logical_link_profile_name = LOCALLL physical_link_profile_name = LOCALPL logical_link_type = token_ring stop_attachment_on_inactivity = no station_type = secondary physical_link_type = token_ring remote_secondary_station_address = 1 smart_modem_command_sequence = length_of_command_sequence = 0 call_type = call x25_level = 1984 listen_name = IBMQLLC autolisten = no timeout_value = 0 remote_link_name_ethernet = remote_link_name_token_ring = remote_link_address = 400000000001 selection_sequence = length_of_selection_sequence = 0 network_type = switched access_routing = link_address remote_sap_address = 04 remote_sap_address_range_lower = 04 remote_sap_address_range_upper = EC virtual_circuit_type = permanent remote_station_X.25_address = optional_X.25_facilities = no logical_channel_number_of_PVC = 1 reverse_charging = no rpoa = no default_packet_size = yes default_window_size = yes default_throughput_class = yes closed_user_group = no closed_user_group_outgoing = no network_user_id = no network_user_id_name = data_network_identification_code = packet_size_for_received_data = 128 packet_size_for_transmit_data = 128 window_size_for_received_data = 4 window_size_for_transmit_data = 4 throughput_class_for_received_data = 1200 throughput_class_for_transmit_data = 1200 index_to_selected_closed_user_group = 0 lu_address_registration = no lu_address_registration_name = LDEFAULT 3. Define the connection profiles The connection profile specifies the LU name of the partner and defines the name that will be used by the APING program to reach the partner. You will again need a connection profile for both listen and call if you want to act as both a client and a server. PARTNER_CONNECTION: type = CONNECTION profile_name = SERVER_LU_LISTEN attachment_profile_name = LISTEN local_lu_profile_name = LOCALLU network_name = NETWORK_NAME remote_lu_name = SERVER_LU stop_connection_on_inactivity = no lu_type = lu6.2 interface_type = extended remote_tpn_list_name = REMOTETPS mode_list_name = MODELIST node_verification = no inactivity_timeout_value = 0 notify = no cp_sessions = no parallel_sessions = parallel negotiate_session_limits = yes security_accepted = conversation conversation_security_access_list_name = PARTNER_CONNECTION: type = CONNECTION profile_name = SERVER_LU_CALL attachment_profile_name = CALL local_lu_profile_name = LOCALLU network_name = NETWORK_NAME remote_lu_name = SERVER_LU stop_connection_on_inactivity = no lu_type = lu6.2 interface_type = extended remote_tpn_list_name = REMOTETPS mode_list_name = MODELIST node_verification = no inactivity_timeout_value = 0 notify = no cp_sessions = no parallel_sessions = parallel negotiate_session_limits = yes security_accepted = conversation conversation_security_access_list_name = - Mode list profiles You will also need mode list profiles: MODE_MODE LIST: type = MODELIST Listname = MODELIST list_members = BATCH,INTER o Configuration changes specific to the client computer No special configuration is needed for AIX SNA Services to configure the APING client. o Configuration changes specific to the server computer - Defining the TP To define the transaction program profiles: LOCAL_TPN LIST: type = TPNLIST Listname = LOCALTPS list_members = APINGDLOCAL APINGDLOCAL_TPN: type = TPN profile_name = APINGDLOCAL tpn_name = APINGD conversation_type = mapped pip_data = no sync_level = confirm recovery_level = no_reconnect full_path_to_tpn = /u/pjs/bin/APINGD multiple_instances = yes user_id = 0 server_synonym_name = restart_action = once communication_type = signals stdin = /dev/null stdout = /u/pjs/log/APINGD.stdout stderr = /u/pjs/log/APINGD.stderr subfields = 0 communication_ipc_queue_key = 0 tpn_name_in_hex = no security_required = none resource_security_access_list_name = REMOTE_REMOTE TPN LIST: type = REMOTETPNLIST Listname = REMOTETPS list_members = APINGD APINGD_REMOTE TPN: type = REMOTETPN profile_name = APINGD tpn_name = APINGD pip_data = no conversation_type = mapped recovery_level = no_reconnect sync_level = confirm tpn_name_in_hex = no +---------------------------------------------------------------------------+ | | | Programmer's Guide | | | +---------------------------------------------------------------------------+ This is a quick guide on how to recompile the source code on your platform. You should only need to refer to this section if you did not receive the executable code with APING, or if you are interested in making changes to the APING source. See the appropriate makefile for your environment: MAKEFILE ENVIRONMENT APING.OS2 Networking Services/2 or Extended Services Only This makefile will build an OS/2 only executable. You must have the OS/2 Programmer's Toolkit installed. See the comments at the start of the makefile for information about setting up your compilation environment. This makefile is written for Microsoft C 6.0. If you would like to use it with IBM C/2, you will need to change the warning flag from "/W4" to "/W3." APING.FAM (Networking Services/2 or Extended Services) and Networking Services/DOS This makefile will build a family API executable that will run in either OS/2 or a DOS environment. You must have the OS/2 Programmer's Toolkit installed, and both an OS/2 CPI-C platform (Networking Services/2 or Extended Services) and Networking Services/DOS See the comments at the start of the makefile for information about setting up your compilation environment. This makefile is written for Microsoft C 6.0. If you would like to use it with IBM C/2, you will need to change the warning flag from "/W4" to "/W3." APING.DOS Networking Services/DOS Only This makefile will build a DOS mode executable. The OS/2 Programmer's Toolkit is NOT required. This makefile is written for Microsoft C 6.0. If you would like to use it with IBM C/2, you will need to change the warning flag from "/W4" to "/W3." APING.BOR Networking Services/DOS Only This makefile will build a DOS mode executable. The OS/2 Programmer's Toolkit is NOT required. This makefile is for use with Borland C++ 2.0. APING.400 AS/400 This file is a REXX exec which should be uploaded to the AS/400. Assuming your compiler is set up to compile C code, you can simply run this exec to build APING and APINGD. APING.AIX AIX SNA Services This makefile is for use with the XCL compiler shipped with the AIX operating system. APING.VM VM ESA This file is a REXX exec which should be uploaded to VM and renamed (for example, to MAKEIT EXEC). Assuming your compiler is set up to compile C code, you can simply run this exec to build APING and APINGD. If you have access to a version of the MAKE utility, the APING.VM file also has a makefile for VM within comments at the end of the file.