|
|
This chapter provides instructions for updating VTAM and MVS on the mainframe, as well as updating the input parameter cards to customize the mainframe application for your site's particular needs. You will use different sections of this chapter depending on whether your connection to the workstation uses LU 6.2 or TCP/IP.
This chapter includes the following main sections:
Use the installation checklist provided in "Mainframe/Workstation Installation Checklist," to coordinate the configuration of the mainframe and workstation components.
You must configure the mainframe to communicate with the CiscoWorks Blue workstation using either LU 6.2 or TCP/IP. See the section that pertains to your protocol.
This section describes how to modify VTAM data sets on a mainframe that is connected to the workstation using LU 6.2.
Before you start, you must configure the mainframe to allow an LU 6.2 session to flow from the workstation to the mainframe. You may need to change VTAM and workstation applications that support LU 6.2 sessions (for example, SNAplus2 or Communication Server for AIX). If the workstation is not directly connected to the mainframe running the mainframe application, but the session passes through one or more VTAMs before reaching the destination VTAM, the correct configuration might require changes to all VTAMs (and possibly the Network Control Programs [NCPs]) in the path. It is not the intent of this book to document all the steps necessary to set up the network. See the relevant VTAM and NCP publications.
If this LU 6.2 setup has not yet been done, delay the installation until the LU 6.2 configuration is complete. One way to determine whether there is LU 6.2 connectivity between the workstation and the mainframe is to issue the following VTAM command:
D NET,APING,ID=NETID.RESOURCEWhere the NETID.RESOURCE is the fully qualified name of the SNA workstation. Until the APING command returns a positive response, the mainframe application cannot connect to the workstation.
After the initial LU 6.2 configuration is complete, use the information in the following section, "Configuring LU 6.2 Connectivity" to complete the configuration.
To configure LU 6.2 connectivity, perform the following steps:
LU 6.2 uses the following LOGMODE entries:
SNASVCMG MODEENT LOGMODE=SNASVCMG,FMPROF=X'13',TSPROF=X'07', X
PRIPROT=X'B0',SECPROT=X'B0',COMPROT=X'D0B1', X
RUSIZES=X'8585',PSERVIC=X'060200000000000000000300', X
ENCR=B'0000'
*
PARALLEL MODEENT LOGMODE=PARALLEL,FMPROF=X'13',TSPROF=X'07',X
PRIPROT=X'B0',SECPROT=X'B0',COMPROT=X'50B1',TYPE=X'00', X
RUSIZES=X'8787',PSERVIC=X'060200000000000000002F00'
*
If your MODETAB table lacks these entries, use a text editor to add them before you reassemble and link-edit the MODETAB table. The text for these table entries is available in prefix.NSPS300.NSPSSAMP(MODEENT). A sample of assembly and link-edit JCL is available in prefix.NSPS300.NSPSSAMP(MODEJCL).
 |
Note If you use Parallel Mode, the RUSIZE values must be at least hex 8787. |
The changes to the MODETAB table take effect when VTAM is restarted. You can load the changes immediately with the following system console command:
MODIFY NET,TABLE,NEWTAB=modetab,OPTION=LOADStep 2 Create a PU definition for the workstation that meets the following requirements:
Additionally, if the PU is defined under an NCP major node, the NCP definition must contain the LUDRPOOL statement for the configuration of at least three independent LUs.
A sample PU definition (defined under a switched major node) is available in prefix.NSPS300.NSPSSAMP(SWMNILU).
Step 3 Define an independent LU under a cross-domain resource (CDRSC) major node, associating the LU with an existing PU. A sample CDRSC definition is available in prefix.NSPS300.NSPSSAMP(NSPCDRSC). Alternatively, you can define an independent LU under an existing PU definition by coding LOCADDR=0.
You can modify the resource names in the sample major node members to your site's naming conventions for network resources, but the same modifications must be made to the parameter cards (See the "Updating the Mainframe Configuration File (NSPPARM)" section).
This section describes how to modify your mainframe TCP/IP installation. TCP/IP connects through Cisco IOS for S/390, Interlink TCP/IP, or IBM TCP/IP.
To use either of these TCP/IP stacks in MVS, make the following changes to the NSPOPEN procedure (located in prefix.NSPS300.NSPSSAMP) or JCL.
//NSPOPEN EXEC PGM=NSPOPEN,PARM='=ICS_SUBSYS=SUBS',
// TIME=1440,REGION=&RGN,
If you are using Cisco IOS 390 Release 1 or TCP Access 4.1 (or earlier), and you are not using the default subsystem name of ACSS, you must apply PTF TP06511 from Interlink/Sterling. PTF TP06511 requires the following other PTFs:
You can obtain all these PTFs from ftp.interlink.com/pub/ptf410. PTFs TP04545 and TP04823 are in the 9712 Cumulative.
If you are using Cisco IOS 390 Release 2, or TCP Access 5.2, you do not need these PTFs.
Complete the following steps to configure systems that use IBM TCP/IP for MVS.
This step is optional. If you reserve specific port numbers, this reservation will flag these port numbers for exclusive use by the mainframe application. Consequently, other products on the mainframe will not use them.
For each workstation, choose two consecutive, available port numbers and add the following two lines to the list of PORT values in your PROFILE.TCPIP file. The default port values are 6104 and 6105, as shown in the following example TCP lines. If you use other port numbers, change the TCP lines in the PROFILE.TCPIP file.
6104 TCP NSPOPEN
6105 TCP NSPOPEN
|
Note The TCP port numbers on the mainframe must match the port numbers on the workstation. |
Step 2 If the TCP/IP address space is not named TCPIP, edit the TCPIP.TCPIP.DATA data set, and verify that the TCPIPJOBNAME or TCPIPUSERID parameter is set correctly to the name of the TCP/IP address space.
Step 3 Ensure that the TCPIP prefix is set correctly in the NSPOPEN procedure (located in prefix.NSPS300.NSPSSAMP) by using one of the following procedures:
//SYSTCPD DD DISP=SHR,DSN=HLQ.NAME(TCPDATA)
PARM='=TCPIP_PREFIX=TCPMVS2.TCPIP1',
Step 4 If you are running IBM TCP/IP V3R4 or later, edit the NSPPARM parameter file and change the TCP_LEVEL card to IV3R4, as described in the "TCP_LEVEL" section.
Step 5 After you make any changes, restart the mainframe application.
Step 6 Verify the TCP/IP connectivity for MVS.
Any TCP/IP client application that is running on OS/390 V2R5 or later, or on TCPIP V3R3, must be defined to the security manager (RACF) with an OMVS segment. If you start the Maps or SNA View mainframe application from the console, first you must add an entry for the procedure in the STARTED class with an Open MVS (OMVS) segment. This segment must assign the OMVS group and userid to the Maps or SNA View mainframe application to connect as a client to TCP/IP OpenEdition.
If you do not add the entry, the following message results:
NSP150 TCP/IP communications: socket() for workstation message agent
failed with error 14
The mainframe application also fails if ports are defined in the PARM data set reserved for BINDs to port 0 in the applicable BPXPRMxx member in the operating system PARMLIB. The following example shows where the ports are defined:
NETWORK DOMAINNAME(AF_INET) DOMAINNUMBER(2) MAXSOCKETS(1000)
TYPE(CINET) INADDRANYPORT(5000) INADDRANYCOUNT(4000)
The second (TYPE) statement reserves ports 5000 through 8999 for BINDs to port 0 and cannot be used in the mainframe application's PARM data set. An attempt to bind to a port in this range will result in the following message:
NSP150 TCP/IP communications: bind() for workstation message agent
failed with error 37
Because CiscoWorks Blue defaults to use ports 6104 and 6105 for communication with the workstation, you should free those ports. One way to do this is by changing the INADDRANYCOUNT value (in the previous example) to 1000, as follows:
NETWORK DOMAINNAME(AF_INET) DOMAINNUMBER(2) MAXSOCKETS(1000)
TYPE(CINET) INADDRANYPORT(5000) INADDRANYCOUNT(1000)
Or, you can choose other available ports. If you choose other ports, make the similar port changes at the workstation.
If you configure TCP/IP connectivity from multiple UNIX workstations, each set of SVMF_HCI_AGENT_PORT and SVMF_CMDS_AGENT_PORT parameters for each mainframe connection must have corresponding TCP parameter cards in the mainframe. (TCP parameter cards are described in the "Updating the Mainframe Configuration File (NSPPARM)" section.) For example, set the workstation parameters on workstation A as follows in the file /etc/svopen_config_DOMAIN:
SVMF_HCI_AGENT_PORT 6104
SVMF_CMDS_AGENT_PORT 6105
You would set the workstation parameters on workstation B as follows in the file
/etc/svopen_config_DOMAIN:
SVMF_HCI_AGENT_PORT 6124
SVMF_CMDS_AGENT_PORT 6125
TCP 6104 6105
TCP 6124 6125
|
Note The TCP port numbers must match the port numbers on the workstation. |
Data transferred between the mainframe and workstation components is not encrypted, but probably will be secure if transferred over a private intranet. If the workstation-to-host connection traverses the Internet, or if additional security is desired over an intranet, you can use the Network Data Encryption with Router Authentication feature. This feature is provided with Cisco routers to encrypt the data that flows between the router nearest to the workstation and the router nearest to the host.
More information about encrypted connections can be found in the Cisco IOS software Security Configuration Guide.
This section describes changes that you must make in your system's MVS and VTAM data sets. These changes are necessary regardless of the method used to connect the workstation to the mainframe. Notify your system programmer of the changes that must be made to the members in the SYS1.PARMLIB data set.
If necessary, reload (re-IPL) MVS. If your system is set up to use dynamic APF services, you can avoid reloading MVS by using the SETPROG command to update the APF list dynamically. See the Initialization and Tuning Reference manual for your MVS/ESA system for more information about authorizing data sets.
Step 2 Set the performance group by adding a TRXNAME parameter for the Maps and SNA View mainframe application to the started task control (STC) subsystem definition of SYS1.PARMLIB(IEAICSxx). In the TRXNAME line, specify the same performance group used by NetView or other high-priority application programs to ensure that the mainframe application receives enough CPU time to avoid a backlog of network information processing.
The default application name for the mainframe application startup job is NSPOPEN.
If NetView is running in performance group 8, and you want the mainframe application also to run in performance group 8, specify the following TRXNAME parameter:
TRXNAME=NSPOPEN,PGN=8After you add a new entry, you can use the following MVS command to dynamically reload the installation control specification (ICS) file:
SET ICS=xxWhere:
xx is the two-digit suffix of the member that was edited.
Step 3 Add an entry to the program properties table in SYS1.PARMLIB(SCHEDxx):
PPT PGMNAME(NSPOPEN)After you add the new entry, you can reload the program properties table immediately with the following MVS command:
SET SCH=xxWhere:
xx is the two-digit suffix of the member that was edited.
Step 4 Add the VTAM parameter PPOLOG=YES to your VTAM startup options in the SYS1.VTAMLST(ATCSTRxx) file to ensure that messages issued by VTAM in response to console commands are sent to the primary program operator.
If the PPOLOG parameter has not been set in the currently running VTAM, you can add it dynamically with the following command:
MODIFY vtamproc,PPOLOG=YESStep 5 Copy and modify the prefix.NSPS300.NSPSSAMP(NSPAPPL) data set.
Step 6 Activate the major node and verify that the APPL definitions are active.
You can modify the APPL resource names in the definition to suit your site's naming conventions for network resources, but the same modifications must be made to the parameter cards described in the "Updating the Mainframe Configuration File (NSPPARM)" section.
Step 7 Install the VTAM exit routine, and allocate the VSAM database, as described in the "Using the Configuration Services XID Exit Routine" section.
This section includes the following subsections:
Maps and SNA View provide a functional XID Configuration Services exit manager that can invoke multiple exit routines. Two instances of the exit manager are built in the NSPSLOAD data set. One instance invokes the Maps and SNA View version of the exit and is named NSPESNAV. The other instance, named NSPESNIS, invokes both the Maps and SNA View version as well as the Internetwork Status Monitor (ISM) version of the exit. Also, you can generate your own NSPEMGR exit to invoke the Cisco-supplied exits as well as an existing exits used at your site. The exit manager lets your ISTEXCCS exit routine coexist with the CiscoWorks Blue exit routines without requiring modifications to your exit routine's source code.
When the SNA View, ISM, and user ISTEXCCS exits are combined with the CiscoWorks Blue exit manager NSPEMGR, some interdependencies exist.
The Maps and SNA View exit logs MAC, SAP, and RIF data to a VSAM data set each time a switched PU connects into the network. You must allocate and prime the VSAM data sets before the exit is activated and the modified VTAM PROC is restarted, as described in the "Allocating and Defining the VSAM Data Sets for the Configuration Services Exit" section.
If you do not have a Configuration Services exit in use (see the "Determining ISTEXCCS Exit Presence" section), install the Maps and SNA View version as described in the "Installing the Maps and SNA View XID Configuration Services Exit Routine" section.
If you have previously installed ISM, and the ISM exit is currently the only exit being handled by the exit manager (you do not have another exit that must be invoked), install the combined ISM and Maps and SNA View version as described in the "Installing the Combined ISM, Maps, and SNA View XID Configuration Services Exit Routine" section.
If you have your own ISTEXCCS exit routine, follow the procedures as described in the "Adding Your Own ISTEXCCS Exit Routine to NSPEMGR" section.
To determine if you have an active ISTEXCCS exit, issue the following command:
D NET,EXIT,ID=ISTEXCCSIf the command shows an active exit, you have an active ISTEXCCS exit. If it indicates an inactive exit, you might have to activate the ISTEXCCS exit. Ask your system programmer to active the ISTEXCCS exit.
If your ISTEXCCS exit is not automatically started with VTAM, you should consider configuring your VTAM program to automatically activate the ISTEXCCS exit so it will be activated when VTAM starts.
To manually activate the ISTEXCCS exit, issue the following command:
f net,exit,opt=act,id=istexccs,module=modulenameWhere:
modulename is the load module name of the exit you will use.
If an ISTEXCCS exit is active and you want to inactivate it, issue the following command:
f net,exit,opt=inact,id=istexccsThis section describes how to calculate the size of the primary and backup databases in SNPDBVSM. Regardless of which exit manager you use, you must allocate and define the VSAM data sets for use by the Maps and SNA View exit.
|
Note All samples must be modified before use. |
a. Estimate the total number of switched PUs that will connect into the VTAM.
b. Multiply the number in step a. by 230.
c. Add a contingency factor (100 percent is suggested).
d. The result is the minimum number of bytes you should allocate for each VSAM database in NSPDBVSM (PRIMARY and BACKUP).
Step 2 Prime the VSAM database using the sample PRIMEJCL in the prefix.NSPS300.NSPSSAMP data set.
Step 3 Add two DD statements to the VTAM start-up procedure to include the data sets allocated in Step 2. The DDNAMEs must be XIDDATA and XIDBACK. Replace the names NSP.XIDDATA1 and NSP.XIDBACK1 with the names of the actual VSAM data sets. The following samples show DD statements:
//XIDDATA DD DSN=NSP.XIDDATA1,DISP=SHARE
//XIDBACK DD DSN=NSP.XIDBACK1,DISP=SHARE
Step 4 Restart VTAM with the VSAM data sets allocated and primed.
If you are not using your own ISTEXCCS exit, use the following procedure to install the Maps and SNA View XID Configuration Services exit routine.
|
Note Before you proceed, back up your ISTEXCCS load module. |
Step 2 Restart VTAM with the VSAM data sets allocated.
If you are already running ISM, use the following procedure:
Step 2 Restart VTAM with the VSAM data sets allocated.
This section describes how to add your old ISTEXCCS exit routine to the exit manager.
A fully functional XID Configuration Services exit routine that logs MAC, SAP, and RIF data arising from switched PU connection activity is provided with this product. If you need to provide other XID related support (in particular, dynamic PU definition or other third-party support) you must configure the SNA View XID Configuration Services exit routine to call your exit routine. Maps and SNA View lets you make these modifications with minimum interdependence and without disrupting existing functions.
Use the following procedures to add exit routines to the Configuration Services exit routine:
Use the following procedure to configure the exit manager to use both the Maps and SNA View exit and your own exit.
|
Note The entry point name might be different than the load module name. |
Step 2 Modify the NSPELNKS member located in the NSPSSAMP data set, changing ISTEXCCS to the correct load module name of your exit.
By default, the combined exit is linked with attributes AMODE(24),RMODE(24) as specified in NSPELNKS. If your exit requires a 31-bit address mode, you can change NSPELNKS to have attributes AMODE(31),RMODE(24) because the supplied SNA View exits will operate with a 31-bit address mode.
Step 3 Modify the ASMEMGR member located in the NSPSSAMP data set as necessary. Change the SYSLMOD data set to a VTAM library data set. Change SYSINC1 to the name of the data set where your current exit load module is located.
Step 4 Submit the ASMEMGR job that is in the NSPSSAMP data set.
Step 5 Save a copy of your current ISTEXCCS exit. Copy and rename the NSPEMGR load modules to ISTEXCSS.
Step 6 Restart VTAM after allocating and priming the VSAM data sets.
Use this procedure to configure the exit manager to use the Maps and SNA View exit, the ISM exit, and your own exit.
|
Note The entry point name might be different than the load module name. |
Step 2 Modify the NSPELNKB member located in the NSPSSAMP data set, changing ISTEXCCS to the correct load module name of your exit.
|
Note By default, the combined exit is linked with attributes AMODE(24),RMODE(24) as specified in NSPELNKB. If your exit requires a 31 bit address mode, you can change NSPELNKB to have attributes AMODE(31),RMODE(24) because the supplied SNA View exits will operate with a 31-bit address mode. |
Step 3 Modify the ASMEMGRB member located in the NSPSSAMP data set as necessary. Change the SYSLMOD data set to a VTAM library data set. Change SYSINC1 to the name of the data set where your current exit load module is located.
Step 4 Submit the ASMEMGRB job that is in the NSPSSAMP data set
Step 5 Save a copy of your current ISTEXCCS exit. Copy and rename the NSPEMGR load modules to ISTEXCSS.
Step 6 Restart VTAM after allocating and priming the VSAM data sets.
The following guidelines will help to ensure that multiple XID Configuration Services exit routines are compatible. When you add your own exit routines to the Configuration Services exit routine, remember that each exit routine you add is an instance of the ISTEXCCS exit routine and that, in theory, it can perform any operation normally done in a single exit routine environment. However, because of practical limitations, some restrictions are necessary. If you plan to use multiple XID Configuration Services exit routines, especially those which provide dynamic PU definitions or other active controls, see the guidelines in this section.
The interface guidelines are identical to those required by the VTAM ISTEXCCS exit routine. For a description, see the VTAM Customization manual. There are two exceptions to the information found in this reference:
The NSPEMGR module allocates all of its working storage from subpool 16. You should use a different subpool for any dynamic storage requests in the exit routines you write. If you must use subpool 16 for dynamic storage requests, ensure that your exit routine does not free subpool 16. If you free subpool 16, program checks will occur in NSPEMGR.
The configuration services XID exit point (ISTEXCCS) is both an active decision point and a passive monitoring point within VTAM. As an active decision point, it permits the installation to control the connection of switched PUs or to dynamically define PUs. As a passive monitoring point, it permits the installation to monitor the connection activity of all switched PUs. In general, these capabilities still exist. However, due to the dual nature of the ISTEXCCS function, and because it is now possible for multiple instances of this exit routine to exist simultaneously, there are guidelines to prevent processing ambiguous and conflicting decisions.
For the purpose of describing these guidelines, it is useful to characterize a given exit routine as either a major exit routine, or a minor exit routine, based on which exit routine has the authority to make connection decisions. The rule implemented by the NSP exit routine manager is as follows:
Do not filter out the following messages:
This section describes the purpose and content of the NSPPARM configuration file (NSPPARM). A sample configuration file is provided in prefix.NSPS300.NSPSSAMP. The configuration file contains a sequence of parameter cards that control the way the mainframe application runs. The configuration file contains three sections; each section contains a sequence of parameter cards. Code all parameter cards in uppercase characters.
|
Note If the mainframe application detects invalid entries in the NSPPARM parameter file, it displays a message indicating the error and terminates. Fix the problem and restart the mainframe application to allow the mainframe application to continue processing the parameters and finish initialization. |
Section 1 of the configuration file contains required control parameter cards that specify which PUs and LUs should be discovered and monitored from the mainframe. Section 2 contains a set of required parameter cards that govern the operation of the mainframe subtasks to discover and monitor PUs and LUs. Section 3 contains an optional parameter card for VTAM commands.
The configuration file is described in the following subsections:
Section 1 of the configuration file contains a set of control parameter cards that specify the PU and LU names that the mainframe application sends to the workstation during discovery and status monitoring. Table 4-1 lists the parameter cards for Section 1.
.
| Parameter Card | Valid Values | Purpose |
|---|---|---|
SNA switched major node names | Specifies a list of SNA switched major nodes whose PUs and LUs will not be discovered. | |
PU 4 names | Specifies a list of PU4 names to be monitored. | |
SNA switched major node names | Specifies a list of SNA switched major nodes whose PUs and LUs will be discovered. | |
OPTION | Specifies the naming convention option by which LU names will be selected for discovery and monitoring. | |
ERROR or WARN | ERROR specifies that only error messages are displayed. WARN specifies that both error and warning messages are displayed. | |
YES or NO | NO specifies the application discovers and monitors all PUs and LUs YES specifies the application discovers and monitors only those associated with SNA switched major nodes. | |
A single load module name per PRELOAD statement | Identifies the load modules that will be loaded and will remain loaded while the NSPOPEN address space is active. | |
[-] PULU_NAME | Specifies, by name, which PUs and LUs are (or are not) discovered and monitored. | |
BASE or IV3R4 | BASE specifies that you are not using IBM TCP/IP V3R4 or later. IV3R4 specifies you are using IBM TCP/IP V3R4 or later. |
If you also use the ONLY_SWITCHED_PUS parameter card with the YES option, then the application discovers and monitors only the switched PUs and LUs that are not associated with the switched major nodes specified on this EXCLUDE_SW_MAJNODES parameter card.
If you use the PULU_FILTER parameter card, then the filters specified in the PULU_FILTER parameter card are applied after the PUs and LUs are filtered by the EXCLUDE_SW_MAJNODES parameter card.
Default
If you do not include an EXCLUDE_SW_MAJNODES parameter card, all PUs and LUs are discovered for all SNA switched major nodes, otherwise not filtered out by another parameter card.
Occurrences
You can include more than one EXCLUDE_SW_MAJNODES parameter card.
Card Syntax
EXCLUDE_SW_MAJNODES NODE1 ... NODEn
Where:
NODE1 ... NODEn specifies the names of one or more SNA switched major nodes, separated by spaces, whose PUs and LUs will be excluded from discovery. You must use the complete node name; wildcard characters are not allowed.
Example
To have the application exclude all PUs and LUs associated with the SNA switched major nodes SWDOM1 and SWDOM2, code the following parameter card:
EXCLUDE_SW_MAJNODES SWDOM1 SWDOM2
You need not specify a PULU_FILTER card. If you do, you must specify the following PU names:
For the mainframe application to discover PU 4-PU 4 connections, the VTAM DD statement must be specified in the NSPOPEN procedure (located in prefix.NSPS300.NSPSSAMP). A VTAM DD card has been supplied as a comment. You can uncomment this card and supply the correct VTAM data set containing the NCP members (substitute your data set name in place of SYS1.VTAMLST):
//VTAM DD DSN=SYS1.VTAMLST,DISP=SHR
Default
If you do not specify an INCLUDE_PU4 parameter card or a PULU_FILTER card, then all PU 4-PU 4 connections will be monitored.
Occurrences
You can include more than one INCLUDE_PU4 parameter card.
Card Syntax
INCLUDE_PU4 [NODE1 [... NODEn]]
Where:
NODE1 [... NODEn] specifies the names, including wildcard characters, of one or more SNA PU 4 nodes (NCP names local to this mainframe), separated by spaces, whose PU 4-PU 4 connections are to be monitored.
You can use the asterisk (*) wildcard in each resource name in the following places:
If a resource name includes an asterisk, then any PU 4 name that meets the wildcard requirements will be included in the list of monitored PU 4 nodes.
Examples
The examples are based on this sample configuration on mainframe HOST1:
Member(NCP1A)
N1G1 GROUP ....
N1G1L1 LINE LOCADD=XXXX3745YYYY,
....
N1G1PU1 PU ADDR=01,
...
N1G1LU1 LU LOCADDR=0,
...
N1G2 GROUP PHYSRSC=N1G1PU1,
...
N1G2L1 LINE ...
N1G2PU1 PU ADDR=04CCCC3745DDDD,
...
N1G2L2 LINE ...
N1G2PU2 PU ADDR=04EEEE3745FFFF,
...
Member(NCP2C)
N2G1 GROUP ....
N2G1L1 LINE LOCADD=XXXX3745YYYY,
....
N2G1PU1 PU ADDR=01,
...
N2G1LU1 LU LOCADDR=0,
...
N2G2 GROUP PHYSRSC=N1G1PU1,
...
N2G2L1 LINE ...
N2G2PU1 PU ADDR=04CCCC3745DDDD,
...
N2G2L2 LINE ...
N2G2PU2 PU ADDR=04EEEE3745FFFF,
...
The following examples show how to use search patterns:
To monitor all PU 4-PU 4 connections for NCP1A and NCP2C, use this card:
INCLUDE_PU4 NCP1A NCP2C
To monitor all PU 4-PU 4 connections for all NCPs with names that begin with the characters NCP1 or NCP2 use this card:
INCLUDE_PU4 NCP1* NCP2*
This is a useful technique for installations that change the NCP name when changes to the NCP generation are made. The original NCP name might start as NCP1A. After the first change, it would be renamed NCP1B, then NCP1C, and so on. Instead of updating the filter card every time the NCP generation is changed, NCP1* matches all these changes.
To monitor all PU 4-PU 4 connections for all PU 4 nodes whose names contain with the character "1" or end in the letter "C", use this card:
INCLUDE_PU4 *1* *C
In this example, we want to monitor the N1G2PU1 connection in NCP1A but not the N1G2PU2 connection in the same NCP. Also, we want to monitor all PUs and LUs with names in the format CWB* or IBD*.
INCLUDE_PU4 NCP1*
PULU_FILTER N1G1* N1G2PU1* CWB* IBU*
If you also use the ONLY_SWITCHED_PUS parameter card with the YES option, then the application discovers and monitors only the PUs and LUs associated with the switched major nodes specified on the INCLUDE_SW_MAJNODES parameter card.
If you also use the PULU_FILTER parameter card, then the filters specified in the PULU_FILTER parameter card are applied after the PUs and LUs are filtered by the INCLUDE_SW_MAJNODES parameter card.
Default
If you do not include an INCLUDE_SW_MAJNODES parameter card, all PUs and LUs are discovered for all SNA switched major nodes, otherwise not filtered out by other parameter cards.
Occurrences
You can include more than one INCLUDE_SW_MAJNODES parameter card.
Card Syntax
INCLUDE_SW_MAJNODES NODE1 ... NODEn
Where:
NODE1 ... NODEn specifies the names of one or more SNA switched major nodes, separated by spaces, whose PUs and LUs will be included in discovery. You must use the complete node name; wildcard characters are not allowed.
Example
To have the application include all PUs and LUs associated with the SWDOM1 and SWDOM2 switched major nodes, code the following parameter card:
INCLUDE_SW_MAJNODES SWDOM1 SWDOM2
Default
If you do not include an LU_CONTROL parameter card, the CONSISTENT option is the default.
Occurrences
You can include only one LU_CONTROL parameter card.
Card Syntax
LU_CONTROL OPTION
Where:
OPTION specifies how LU names are selected for discovery and monitoring. The following options are available:
WOMPU1 PU
WOMPU100 LU LOCADDR=00 PULU_FILTER WOM1*
WOMPU101 LU LOCADDR=01
WOMPU2 PU
WOMPU200 LU LOCADDR=00 PULU_FILTER WOM2*
WOMPU201 LU LOCADDR=01
PU_LU_FILTER WOM*
PU0000 PU
LU000000 LU LOCADDR=00
LU000001 LU LOCADDR=01
PU0001 PU
LU000100 LU LOCADDR=00
LU000101 LU LOCADDR=01
Example
To have the application discover LUs based on a consistent PU and LU naming convention, code the following parameter:
LU_CONTROL CONSISTENT
AP000 PU
AP000L00 LU LOCADDR=00
AP000L01 LU LOCADDR=01
AP001 PU
AP001L00 LU LOCADDR=00
AP001L01 LU LOCADDR=01
BP000 PU
BP000L00 LU LOCADDR=00
BP000L01 LU LOCADDR=01
BP001 PU
BP001L00 LU LOCADDR=00
BP001L01 LU LOCADDR=01
PULU_FILTER AP* BP*
LU_CONTROL UNIQUE
PUA000 PU
LUA00000 LU LOCADDR=00
LUA00001 LU LOCADDR=01
PUA001 PU
LUA00100 LU LOCADDR=00
LUA00101 LU LOCADDR=01
PUB000 PU
LUB00000 LU LOCADDR=00
LUB00001 LU LOCADDR=01
PUB001 PU
LUB00100 LU LOCADDR=00
LUB00101 LU LOCADDR=01
PULU_FILTER PUA* LUA* PUB* LUB*
If LU_CONTROL was set to CONSISTENT with the following PULU_FILTER:
PULU_FILTER PUA* PUB*
The status of the logical units would be sent to the workstations during discovery. The status of the associated logical units are sent because the PU passes one or more PULU_FILTERs. However, later status updates for the logical units would not be sent to the workstations.
When NSPOPEN receives a status update for a logical unit, it evaluates the logical unit's name against the specified PULU_FILTERs. In this case, the logical units will not pass any filters preventing their status information from flowing to workstations.
If LU_CONTROL was set to consistent with the following PULU_FILTER, the status of the logical units would be sent to the workstations during discovery. However, later status updates would not be sent to the workstations.
PULU_FILTER PUA* PUB*
Use the MSG_LEVEL parameter card to specify whether warning messages are displayed.
Default
If you do not supply a MSG_LEVEL parameter card, ERROR is used.
Occurrences
You can include only one MSG_LEVEL parameter card.
Card Syntax
MSG_LEVEL [ERROR | WARN]
Where:
|
Note The ONLY_SWITCHED_PUS card is supported only in VTAM V4R3 and higher. If you are using a version of VTAM earlier than V4R3, use ONLY_SWITCHED_PUS NO. |
Default
YES is the default: the mainframe application will discover and monitor only PUs and LUs associated with SNA switched major nodes.
Occurrences
You can include only one ONLY_SWITCHED_PUS parameter card.
Card Syntax
ONLY_SWITCHED_PUS {YES | NO}
Where:
{YES | NO} specifies whether the application will discover and monitor only PUs and LUs associated with an SNA switched major node.
Example
To have the application discover and monitor only PUs and LUs associated with an SNA switched major node, code the following parameter card:
ONLY_SWITCHED_PUS YES
Use the PRELOAD parameter card to identify load modules, which will be loaded and will remain loaded while the NSPOPEN address space is active. This parameter card is used to improve performance when a particular load module is being loaded and unloaded frequently.
|
Note Use of this card is normally something Cisco TAC may recommend. |
Default
If no parameter is specified then no PRELOADS are performed.
Occurrences
You can include several PRELOAD parameter cards. Only one load module name is allowed on each preload statement.
Card Syntax
PRELOAD
Example
To preload load module L$CALMTO, code the following parameter card:
PRELOAD L$CALMTO
Each PULU_FILTER parameter card contains one or more filter tokens to be applied to the PU and LU names. Each filter token is a portion of an PU or LU name, and includes asterisks (*) as wildcards at the beginning of the name, at the end of the name, or both. For example, to specify all PUs and LUs with names beginning with ABC, you would code a filter token as ABC*.
If you precede a filter token with a hyphen (-), PUs and LUs that match that filter token are not discovered.
Default
If you do not supply a PULU_FILTER parameter card, all PUs and LUs will be discovered and monitored regardless of naming conventions, unless filtered out by other parameter cards.
Occurrences
You can include several PULU_FILTER parameter cards.
Card Syntax
PULU_FILTER [-]FILTER_TOKEN1 . . . [-]FILTER_TOKENn
Where:
[-] specifies that PU and LU names that satisfy the following FILTER_TOKEN values will be ignored (not discovered).
If you omit the - character, then PU and LU names that satisfy the following FILTER_TOKEN values will be discovered.
FILTER_TOKEN1 ... FILTER_TOKENn specifies one or more filter tokens, each consisting of a portion of a PU or LU name with asterisks to be used as wildcards. You can code a series of filters on the same PULU_FILTER parameter card.
Each filter token must contain at least one asterisk at the beginning or end of the token. Each filter token can contain two asterisks, one at each end. The following tokens are valid:
Examples
To discover and monitor only those PUs and LUs beginning with the characters VPU, but to ignore PUs and LUs beginning with the characters VPU5, code the following parameter card:
PULU_FILTER VPU* -VPU5*
To discover and monitor all PUs and LUs beginning with the characters ABC, ending with the characters DEF, or containing the characters GHI, code the following parameter card:
PULU_FILTER ABC* *DEF *GHI*
Use the TCP_LEVEL card to identify whether you are running the IBM TCP/IP V3R4 (or later) protocol stack.
Default
If you do not supply a TCP_LEVEL parameter card, BASE is used.
Occurrences
You can include only one TCP_LEVEL parameter card.
Card Syntax
TCP_LEVEL [BASE | IV3R4]
Where:
Section 2 of the configuration file contains a set of parameter cards that govern the operation of the mainframe subtasks that discover and monitor PUs and LUs. Table 4-2 lists the parameter cards you can use in Section 2.
.
| Parameter Card | Valid Values | Purpose |
|---|---|---|
VTAM APPL definition | Specifies a VTAM APPL definition for SNA PU and LU discovery. | |
Console name | Provides the application with MVS console support. | |
None | Requests setup of the program-to-program interface (PPI) to NetView or SOLVE:Netmaster. | |
VTAM APPL definition | Specifies a VTAM APPL definition for a primary program operator (PPO) application; allows the application to act as VTAM primary program operator. | |
BLOCK, NO | Specifies the security method for workstation users when issuing mainframe commands. | |
APPL, LU, mode, message server, command server | Identifies VTAM resources for LU 6.2 workstation connection. | |
VTAM APPL definition | Specifies a VTAM APPL definition for SNA PU and LU status updates. | |
Host connection interface port, host command server port | Identifies port numbers for TCP/IP workstation connection. |
Default
You must supply a DISCOVER parameter card; NSPDSC1 is the default value.
Occurrences
You can include only one DISCOVER parameter card.
Card Syntax
DISCOVER VTAM_applid
Where:
VTAM_applid specifies the name of a VTAM APPL definition card coded with AUTH=SPO. This APPL ID identifies an application that will discover SNA PUs and LUs. The named application is authorized to issue VTAM DISPLAY commands during the discover process.
In the prefix.NSPS300.NSPSSAMP(NSPAPPL) member, the sample discovery VTAM APPL is named NSPDSC1.
Example
If the ID of the discover subtask's APPL definition, coded with AUTH=SPO, is NSPDSC1, you would code the following DISCOVER parameter card:
DISCOVER NSPDSC1
Default
If you do not supply an MVS parameter card, and the exit is forced to switch to the backup VSAM data set, the mainframe application is not notified.
Occurrences
You can include only one MVS parameter card.
Card Syntax
MVS console_name
Where:
console_name is the name of the extended MCS console to be defined for receipt of MVS messages. If this name is defined in RACF, the OPERPARM values for this name are used for the console definition. Otherwise, a console is defined with default parameters AUTH=INFO and ROUTCDE=ALL.
Example
To specify NSPCONS1 as the extended MCS console, use the following MVS parameter card:
MVS NSPCONS1
Use the PPI parameter card to connect the application to the NetView or SOLVE:Netmaster PPI for the receipt of VTAM messages. The PPI card tells the application to establish a program-to-program interface with NetView or SOLVE:Netmaster so that the application can receive solicited and unsolicited VTAM messages. The PPI must be active in accordance with the NetView or SOLVE:Netmaster documentation.
Default
You must supply a PPI or PPO parameter card.
Occurrences
You can include only one PPI parameter card.
Card Syntax
PPI
Example
To connect the application to the NetView or SOLVE:Netmaster PPI for receiving VTAM messages at the workstation, code the following PPI parameter card:
PPI
|
Note Do not include a PPI card if neither NetView nor SOLVE:Netmaster is present on the system. Instead, use the PPO parameter card to specify a primary program operator. |
Use the PPO parameter card to specify the name of a VTAM APPL definition that will act as a primary program operator application program (PPO) to receive solicited and unsolicited VTAM messages.
|
Note Do not include a PPO parameter card if the application is running in combination with other management software, such as NetView or SOLVE:Netmaster; only one application in a domain can be the primary program operator. Instead, use the PPI parameter card to connect the application to NetView or SOLVE:Netmaster. |
Default
You must supply a PPI or PPO parameter card.
Occurrences
You can include only one PPO parameter card.
Card Syntax
PPO VTAM_applid
Where:
VTAM_applid is the ID of the APPL definition coded with AUTH=PPO. This identifies the primary program operator application program that will receive unsolicited VTAM messages.
Example
If the ID of the APPL definition coded with AUTH=PPO is NSPPPO1, code the following PPO parameter card:
PPO NSPPPO1
Use the SEC parameter card to specify the security clearance level needed to activate and deactivate SNA resources from the workstation.
Default
If you do not supply an SEC parameter card, BLOCK is used.
Occurrences
You can include only one SEC parameter card.
Card Syntax
SEC [BLOCK | NO]
Where:
BLOCK means that workstation users cannot issue mainframe commands. This is the default. The SPO subtask will not be started even if you provide the parameter card: the card is not needed because workstation commands are not allowed. If you omit this parameter, BLOCK is the default value.
If you use the BLOCK option, remove any SPO cards from the parameter file.
NO means that any workstation user can issue mainframe commands.
Example
To prevent workstation users from issuing mainframe commands, use the following parameter card:
SEC BLOCK
Use the SERVER parameter card to provide the values needed to establish an LU 6.2 connection between the mainframe application and the workstation application.
Default
If you do not supply a SERVER parameter card, no LU 6.2 sessions are established. Code a TCP card to configure a TCP/IP connection instead. You must provide at least one SERVER or TCP card.
Occurrences
You can include up to ten SERVER parameter cards, one for each workstation attached using LU 6.2.
Card Syntax
SERVER plu slu PARALLEL NSPOPNMS NSPOPNCS
Where:
plu is the label of the VTAM APPL definition you coded with APPC=YES, which is the primary LU for the application at the mainframe.
slu is the label of a CDRSC for the independent secondary LU defined for the workstation and associated with the workstation PU.
PARALLEL is the logmode protocol. Enter PARALLEL.
NSPOPNMS is the name of the SNA LU 6.2 transaction program for the workstation message server.
NSPOPNCS is the name of the SNA LU 6.2 transaction program for the workstation command server.
Example
To define an LU 6.2 session between primary logical unit NSPAPL1 and secondary logical unit NSPLU01 using the logmode PARALLEL, code the following SERVER parameter card:
SERVER NSPAPL1 NSPLU01 PARALLEL NSPOPNMS NSPOPNCS
The STATUS parameter card specifies a VTAM APPL definition that will update the status of SNA PUs and LUs.
Default
None. The STATUS card is required.
Occurrences
You can include one STATUS parameter card.
Card Syntax
STATUS VTAM_applid delay_time
Where:
VTAM_applid is the ID on an APPL definition card coded with AUTH=SPO. The APPL ID identifies a VTAM application, which will update the status of SNA PUs and LUs.
In the prefix.NSPS300.NSPSSAMP(NSPAPPL) data set, the sample status VTAM APPL is named NSPSTA1.
delay_time is the time delay (in seconds) before asking VTAM for the status of a resource. The default is 10 seconds. This delay time allows VTAM to synchronize before collecting PU details.
If the application detects a PU in the pending state after VTAM issues the IST590I message (IST590I indicates that a connection is established), the application retries the display of the PU in a minimum of 10 seconds and continues to retry the display 100 times. If at that point the PU is still pending, the application no longer queries its status. Instead, the application displays message NSP039, which indicates you need to increase the value of delay_time.
Example
If the ID of the status program's APPL definition, coded with AUTH=SPO, is NSPSTA1, code the following parameter card:
STATUS NSPSTA1
Use the TCP parameter card to configure a TCP/IP connection between the mainframe application and the workstation application. Specify the TCP/IP ports on the mainframe used for the host connection interface and the host command server.
|
Note If you are using only an LU 6.2 session between the workstation and mainframe, either remove this card from the NSPPARM file or comment it out. |
Default
If you do not supply a TCP parameter card, no TCP/IP connections are available. Code a SERVER card to establish an LU 6.2 session instead. You must provide at least one SERVER or TCP card.
Occurrences
You can include up to 20 TCP parameter cards (1 for each workstation attached using TCP/IP).
Card Syntax
TCP hciport cmdport
Where:
hciport is the port number opened on the mainframe for establishing a TCP socket connection with the host connection interface on the workstation.
cmdport is the port number opened on the mainframe for establishing a TCP socket connection with the host command server on the workstation.
Example
To reserve ports 6104 and 6105 on the mainframe for the workstation host-connection interface and host command server, code the following TCP parameter card:
TCP 6104 6105
|
Note The TCP port numbers on the mainframe must match the port numbers on the workstation. |
Section 3 of the configuration file contains an optional parameter card that lets the workstation user issue VTAM commands. Table 4-3 shows the parameter card in Section 3.
| Parameter Card | Valid Values | Purpose |
|---|---|---|
VTAM APPL definition | Defines a secondary program operator (SPO) application that allows the workstation to activate and deactivate SNA resources. |
Use the SPO parameter card to define a secondary program operator application program. You must provide one SPO card to be able to activate and deactivate LUs and PUs from the workstation Motif applications.
To prevent workstation users from activating and deactivating SNA resources, do not provide an SPO card. Code the BLOCK option on the SEC parameter card to override an SPO parameter card.
In the default NSPPARM file, this card has a comment delimiter so that it is not read as a parameter card. If you leave this card commented out in the NSPPARM file, workstation users cannot activate and deactivate SNA resources. If you need this card at a later time, you can remove the comment delimiter.
Default
If you do not supply an SPO parameter card, users cannot activate and deactivate SNA resources from a workstation.
Occurrences
You can include only one SPO parameter card.
Card Syntax
SPO VTAM_applid
Where:
VTAM_applid is the name on an APPL definition card coded with AUTH=SPO. The APPL ID identifies an SPO application that will receive solicited messages generated by Activate and Deactivate commands issued from the workstation.
In the prefix.NSPS300.NSPSSAMP(NSPAPPL) member, the sample SPO VTAM APPL is named NSPSPO1.
Example
If the ID of the APPL definition coded with AUTH=SPO is NSPSPO1, code the SPO parameter card:
SPO NSPSPO1
This section describes how to update NetView. To update NetView, use the following subsections:
|
Note Customizing NetView is a required step the product to function properly. You must restart NetView for the changes to take effect. |
If you are using Tivoli NetView for OS/390 Version 1.1 or later, SNA View and Maps can use the NetView automation facilities rather than the CiscoWorks Blue PPI task. This change improves performance of the status updates. To make this change, edit the NSPSVTBL member, and change the current automation table statement.
Verify that the NetView subsystem address space is active and that the NetView PPI is enabled, as defined in the NetView Installation and Administration Guide. The NetView program-to-program interface is necessary for cross-memory communications with NetView. Before starting NetView, start the subsystem application.
To change the NetView DSIPARM data set, use the following procedure:
TASK MOD=NSPVPPI,TSKID=NSPVPPI,PRI=8,INIT=Y
Verify that the NetView task (CNMCSSIR) is defined with INIT=N, and that CNMCSSIR is started in command list CNME1035 during NetView initialization. This task provides command and message forwarding services.
Step 2 Define a command model for the NSPMQS load module by adding the following definition to the DSICMD member of your NetView's DSIPARM data set:
NSPMQS CMDMDL MOD=NSPMQS,RES=N
Step 3 Define an additional NetView autotask, here named NSPAUTO1, by adding the following definition to the DSIOPF member of your NetView's DSIPARM data set:
NSPAUTO1 OPERATOR PASSWORD=PASSWORD
PROFILEN NSPPROF
You can change the Operator ID (NSPAUTO1) to conform to your site requirements, but it must match the value used in the automation table entry (NSPSVTBL) for the NSPSVTAM CLIST. If you change this operator ID, you must change it also in the NSPSVTBL entry.
You can change the PROFILEN name (NSPPROF) to conform to your site requirements. The profile is defined in Step 4.
You might also need to define the Operator ID to the security product.
Step 4 Define a profile for the new NetView autotask (defined as NSPAUTO1 in Step 3) by adding a member named NSPPROF to your NetView's DSIPRF data set. NSPPROF must contain the following three lines:
NSPPROF PROFILE
AUTH MSGRECVR=NO,CTL=GLOBAL
END
You can change the member name to conform to your site requirements, but it must match the PROFILEN statement that was coded in Step 3.
AUTOTASK OPID=NSPAUTO1
Copy the NSPSVTAM member from prefix.NSPS300.NSPSCLST to a NetView CLIST data set (DISCLD).
If you are running NetView 2.3 or NetView 2.4 on the host, the NSPSVTAM command list in the NetView DSICLD dataset concatenation should be updated. The PIPE PPI stage used in the command list is not available on NetView 2.3 or 2.4 so the NSPSVTAM command should be replaced with the following 3 lines of code:
&CONTROL ERROR
&DATA = &CONCAT X'0006' &PARMSTR
NSPMQS NSPVPPI &DATA
The sample library (prefix.NSPS300.NSPSSAMP) contains the following programs you must add to customize NetView:
Create the load modules (NSPVPPI, NSPMQS) by modifying and submitting the JCL in prefix.NSPS300.NSPSSAMP(ASMJCL), according to the instructions in the member. After the load modules are created, copy them to a NetView STEPLIB data set.
Restart NetView to activate the changes that you made to NetView.
This section describes how to enable the mainframe application to interact with SOLVE:Netmaster. You do not have to restart SOLVE:Netmaster for the changes to take effect.
To enable SOLVE:Netmaster to work with the mainframe application, use the procedures in the following subsections:
The data set members listed in Table 4-4 are located in prefix.NSPS300.NSPSCLST and are used to change SOLVE:Netmaster for the mainframe application.
Verify that the SOLVE:Netmaster PPI address space is active, as defined in the SOLVE:Netmaster Implementation and Administration Guide. The PPI is necessary for cross-memory communications between SOLVE:Netmaster and the mainframe application.
For the mainframe application to receive system message information from SOLVE:Netmaster, the network control language (NCL) code in prefix.NSPS300.NSPSCLST(NSPKPPO) must be added to the production PPO procedure (PPOPROC) at a point where all messages will be seen. The recommended point for this code addition is immediately following the mainline &PPOREAD.
For the PPO procedure to receive solicited and unsolicited VTAM messages, those messages must be sent to the PPO procedure by SOLVE:Netmaster. You can use the DEFMSG command to control which messages are sent to the PPO procedure. See the SOLVE:Netmaster documentation for more information.
Copy the following members from prefix.NSPS300.NSPSCLST to a SOLVE:Netmaster command data set (the COMMAND DD card): NSPKCMD, NSPKCM1, and NSPKPPI.
The NSPKPPI and NSPKCMD PROCs are the principal PPI procedures that send PPO data through the PPI and wait for commands coming through the PPI. The NSPKPPI and NSPKCMD PROCs must be active at all times and must run in a background environment within SOLVE:Netmaster. To accomplish this, add the following statements to your NMINIT or NMREADY initialization PROCs:
Sub BSYS NSPKPPI
Sub BSYS NSPKCMD
|
Note You can also issue these as commands from an MCS console. |
When you complete all updates to SOLVE:Netmaster, you can issue the following command to verify correct installation:
SH PPIUSERSThe command displays two receivers, SNAVIEW and NSPNETV, and indicates the number of messages queued so you can monitor the number of messages sent to the mainframe application.
Posted: Thu Mar 22 10:46:38 PST 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.