|
|
This chapter contains 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 contains the following major sections:
Use the installation checklist provided in the appendix "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. If your workstation uses a TCP/IP connection, see the "Configuring TCP/IP Connectivity" section.
Before you start the steps that allow the workstation to communicate with the mainframe, you must complete the necessary configuration to allow an LU 6.2 session to flow from the workstation to the mainframe. You might need to change both VTAM and the workstation application that supports LU 6.2 sessions (for example, SNAplus2 or Communication Server for AIX). If the workstation is not directly connected to the mainframe that runs the mainframe application, but the session passes through one or more VTAMs before reaching the destination VTAM, then 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 instead.
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 VTAM command D NET,APING,ID=NETID.RESOURCE, where 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 procedures in the following section to complete the configuration.
To configure LU 6.2 connectivity, perform the following steps:
Step 1 Ensure that your MODETAB table entry contains the MODENT entries (SNASVCMG and PARALLEL) shown in this example.
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.NSPS210I.NSPSSAMP(MODEENT). A sample of assembly and link-edit JCL is available in prefix.NSPS210I.NSPSSAMP(MODEJCL).
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=LOAD
Step 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.NSPS210I.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.NSPS210I.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 any changes to these default names must also be made to the parameter cards (see the section "Updating the Mainframe Configuration File (NSPPARM)").
This section tells you how to modify your mainframe TCP/IP installation. TCP/IP connects through Cisco IOS for S/390, IBM TCP/IP, or Interlink TCP/IP.
To use either of these TCP/IP stacks in MVS, make the following changes to the NSPOPEN procedure or JCL.
//NSPOPEN EXEC PGM=NSPOPEN,PARM='=ICS_SUBSYS=SUBS',
// TIME=1440,REGION=&RGN,
Complete the following steps to configure systems that use IBM TCP/IP for MVS.
Step 1 Reserve port numbers in the PROFILE.TCPIP file.
This step is optional. If you do not reserve specific port numbers for the mainframe application, the workstation connection will still be successful. This reservation flags the chosen port numbers for exclusive use by the application so that 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 sample TCP lines. If you use other port numbers, change the TCP lines in the PROFILE.TCPIP file.
6104 TCP NSPOPEN
6105 TCP NSPOPEN
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 correctly set 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.NSPS210I.NSPSSAMP). Do one of the following:
//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 section "TCP_LEVEL".
Step 5 Restart the mainframe application after you make any changes.
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, you must first add an entry for the procedure in the STARTED class with an Open MVS (OMVS) segment that assigns the OMVS group and userid to the Maps or SNA View mainframe application so that it can 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 hmessage agent failed with errno 14
The mainframe application also fails if ports are defined in the PARM dataset that are 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 dataset. 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 errno 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)
Otherwise, you can just choose alternate ports that are available.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 section "Updating the Mainframe Configuration File (NSPPARM)".) 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
The data that is transferred between the mainframe and workstation components is not encrypted, but it will probably be secure if the data is 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 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.
Step 1 Authorize LOADLIB (prefix.NSPS210I.NSPSLOAD) by adding the data set prefix.NSPS210I.NSPSLOAD and its direct access storage device (DASD) volume name to your list of authorized program facility (APF) authorized data sets in SYS1.PARMLIB(IEAAPFxx) or SYS1.PARMLIB(PROGxx). Doing this lets the mainframe application process some authorized commands and perform security checks.
Reload (re-IPL) MVS if necessary. If your system is set up to use dynamic APF services, you can avoid reloading MVS by using the SETPROG command to dynamically update the APF list. 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 to also run in performance group 8, specify the following TRXNAME parameter:
TRXNAME=NSPOPEN,PGN=8
After you add a new entry, you can use the following MVS command to dynamically reload the installation control specification (ICS) file:
SET ICS=xx
Where 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)
NOSWAP
SYST
After you add the new entry, you can immediately reload the program properties table with the following MVS command:
SET SCH=xx
Where 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=YES
Step 5 Copy and modify the prefix.NSPS210I.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 any changes to these default names must also 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.
Maps and SNA View provide a functional XID Configuration Services exit manager that allows for the invocation of multiple exit routines. There are two instances of the exit manager already built in the NSPSLOAD dataset. One invokes the Maps and SNA View version of the exit and is named NSPESNAV. The other invokes both the Maps and SNA View version and the Internetwork Status Monitor (ISM) version of the exit, which can be used with both products, and is name NSPESNIS. You can also generate your own NSPEMGR exit that will invoke the Cisco supplied exits as well as an existing exit 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.
The Maps and SNA View exit logs MAC, SAP, and RIF data to a VSAM dataset each time a switched PU connects into the network. You must allocate the VSAM datasets before the exit is activated and the modified VTAM PROC is restarted, as described in the "Allocating and Defining the VSAM Datasets for the Configuration Services Exit" section.
If you do not currently have a Configuration Services exit in use (see the section "Determining ISTEXCCS Exit Presence"), install the Maps and SNA View version as described in the section "Installing the Maps and SNA View XID Configuration Services Exit Routine".
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 section "Installing the Combined ISM, Maps, and SNA View XID Configuration Services Exit Routine".
If you have your own ISTEXCCS exit routine, follow the procedures as described in the section "Adding Your Own ISTEXCCS Exit Routine to NSPEMGR".
One way to determine whether you have an active ISTEXCCS exit is to issue this command:
D NET,EXIT,ID=ISTEXCCS
If the command shows an active exit, you have an active ISTEXCCS exit. If it indicates an inactive exit, you might have an active ISTEXCCS exit, and you should ask your system programmer.
Regardless of which exit manager you use, you must first allocate and define the VSAM datasets for use by the Maps and SNA View exit.
Step 1 Use the sample member provided in
prefix.NSPS210I.NSPSSAMP(NSPDBVSM) to allocate two VSAM databases used by the NSPEXCCS exit routine. Use the following formula to calculate the size of both the PRIMARY and BACKUP databases in NSPDBVSM:
(a) Estimate the total number of switched PUs that will connect into the VTAM.
(b) Multiply the number in (a) by 230.
(c) Add a contingency factor (100 percent is suggested).
(d) The result is the minimum number of bytes to allocate for each VSAM database in NSPDBVSM (PRIMARY and BACKUP).
Step 2 Prime the VSAM database using the sample PRIMEJCL in the prefix.NSPS210I.NSPSSAMP data set.
Step 3 Add two DD statements to the VTAM start-up procedure to include the data sets allocated in the previous step. 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.
Step 1 Copy the NSPESNAV exit routine from the Maps and SNA View NSPSLOAD library to the VTAM library, and rename it ISTEXCCS.
Step 2 Restart VTAM with the VSAM data sets allocated.
If you are already running ISM, use the following procedure:
Step 1 Copy the NSPESNIS exit routine from the Maps and SNA View NSPSLOAD library to the VTAM library, and rename it ISTEXCCS.
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 that arises 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:
If you already have ISM and your own exit routine, use the following procedure to configure the exit manager to use both the Maps and SNA View exit and your own exit.
Step 1 Modify the NSPECCSL source module located in the NSPSAMP dataset, changing the instance of ISTEXCCS to the name of the entry point of the old exit if it is not ISTEXCCS.
Step 2 Modify the NSPELNKS member located in the NSPSSAMP dataset, changing ISTEXCCS to the correct load module name of your exit if it is not ISTEXCCS.
Step 3 Modify the NSPEMGR member located in the NSPSSAMP dataset as necessary. Change the SYSLMOD dataset to a VTAM library dataset. Change SYSINC1 to the name of the dataset where your current exit load module is located.
Step 4 Submit the ASMEMGR job that is in the NSPSSAMP dataset.
Use this procedure to configure the exit manager to use the Maps and SNA View exit, the ISM exit, and your own exit.
Step 1 Modify the NSPECCSL source module located in the NSPSAMP dataset. Comment out the current entry and uncomment the entry for SNA View, ISM and the User Exit, the entry that has NAMES=(ISTEXCCS,NSPSVRIN,NSPSVRI2). Change the instance of ISTEXCCS to the name of the entry point of the current exit if it is not ISTEXCCS.
Step 2 Modify the NSPELNKB member located in the NSPSSAMP dataset, changing ISTEXCCS to the correct load module name of your exit if it is not ISTEXCCS.
Step 3 Modify the NSPEMGRB member located in the NSPSSAMP dataset as necessary. Change the SYSLMOD dataset to a VTAM library dataset. Change SYSINC1 to the name of the dataset where your current exit load module is located.
Step 4 Submit the ASMEMGR job that is in the NSPSSAMP dataset
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 that 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 that provide dynamic PU definitions or other active controls, see the guidelines in this section.
The interface requirements are identical to those required by the VTAM ISTEXCCS exit routine. For a description of these, 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 that you write. If you must use subpool 16 for dynamic storage requests, ensure that your exit routine does not then 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, because of the dual nature of the ISTEXCCS function and the fact that 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 purposes 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:
If you have an exit routine that makes accept and reject decisions for switched PUs, place it first in the list of exit routines in the NSPCCS macro; the NSPEMGR module makes it the major exit routine. All other exit routines are minor exit routines.
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.NSPS210I.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.
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 should send 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 how LU names should be selected for discovery and monitoring. | |
ERROR or WARN | WARN specifies that both error and warning messages are displayed. ERROR specifies that only error messages are displayed. | |
YES or NO | Specifies whether the application discovers and monitors all PUs and LUs, or just those associated with SNA switched major nodes. | |
[-] PULU_NAME | Specifies, by name, which PUs and LUs are (or are not) be discovered and monitored. | |
BASE or IV3R4 | IV3R4 specifies you are using IBM TCP/IP V3R4 or later; BASE specifies that you are not 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 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 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, that are not otherwise 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 also specify a PULU_FILTER card, you must specify the following PU names:
VTAM DD Card
For the mainframe application to be able to discover PU 4-PU 4 connections, the VTAM DD statement must be specified in the NSPOPEN procedure. A VTAM DD card has been supplied as a comment. You can uncomment this card and supply the correct VTAM dataset containing the NCP members (substitute your dataset 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:
1. To monitor all PU 4-PU 4 connections for NCP1A and NCP2C, use this card:
INCLUDE_PU4 NCP1A NCP2C
2. 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.
3. 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
4. In this example we want to monitor the N1G2PU1 connection in NCP1A but not the N1G2PU2 connection in the same NCP. We also 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 that are 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 that are not otherwise 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
Use the LU_CONTROL parameter card to specify how LUs should be discovered and monitored.
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:
Examples
To have the application discover LUs based on a consistent PU and LU naming convention, code the following parameter:
LU_CONTROL CONSISTENT
If you have an inconsistent naming convention, for example where a PU named IBUPC1 has LUs named PC1LU01 and PC1LU02. The application considers this an inconsistent naming convention. In this case, for the IBUPC1 PU and its associated LUs to be discovered and monitored, you should code the following:
LU_CONTROL UNIQUE
PULU_FILTER IBU* PC1*
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:
Default
YES is the default: the mainframe application will discover and monitor only PUs and LUs that are 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
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 that begin with the characters VPU, but to ignore PUs and LUs that begin with the characters VPU5, code the following parameter card:
PULU_FILTER VPU* -VPU5*
To discover and monitor all PUs and LUs that begin with the characters ABC or end with the characters DEF, or contain 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.NSPS210I.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 dataset, 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 are 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
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.
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 mainframe application and a 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 that 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 that will update the status of SNA PUs and LUs.
In the prefix.NSPS210I.NSPSSAMP(NSPAPPL) data set, the sample status VTAM APPL is named NSPSTA1.
delay_time is the number of seconds to delay before asking VTAM for status. The default is 10 seconds.
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 for 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 that you might 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. You specify the TCP/IP ports on the mainframe that are used for the host connection interface and the host command server.
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
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 to allow the workstation 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.
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.NSPS210I.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 explains the steps that are required to use NetView. The following subsections are included in this section:
If you are using Tivoli NetView for OS/390 version 1.1 or later, SNA View and Maps can use the new 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 automation table statement that is used, as described in the "Choosing the Automation Table Statement" section.
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.
Follow these steps to change the NetView DSIPARM data set.
Step 1 Define the mainframe optional task by adding the following definition to the DSIDMN member of your NetView's DSIPARM data set:
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 also change it 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
Step 6 Copy the NSPSVTBL member from prefix.NSPS210I.NSPSAMP to a NetView DSIPARM dataset. Add an include for NSPSVTBL in the current automation table member (%INCLUDE NSPSVTBL).
The NSPSVTBL member has two sections that let you decide which automation table statement to use. The first automation table statement, which is the default statement (it is not commented), always works regardless of which level of NetView you are using.
IF (MSGID='IST093I' | MSGID='IST105I' | MSGID='IST259I' |
MSGID='IST590I' | MSGID='IST619I' | MSGID='IST621I' |
MSGID='IST1132I' | MSGID='IST1133I' | MSGID='IST1416I') &
TEXT=MESSAGE
THEN EXEC(CMD('NSPSVTAM ' MESSAGE)
ROUTE(ONE NSPAUTO1));
The second automation table statement (commented) is for NetView V1R1 or later. It provides a direct PPI communication using NetView pipelines and gives better performance. To use this statement, comment out all the lines of the first statement and uncomment all the lines of the second statement.
IF (MSGID='IST093I' | MSGID='IST105I' | MSGID='IST259I' |
MSGID='IST590I' | MSGID='IST619I' | MSGID='IST621I' |
MSGID='IST1132I' | MSGID='IST1133I' | MSGID='IST1416I')
THEN EXEC(CMD('PIPE (NAME NSP2PPI END ¨) SAFE * '
'| EDIT /0006/ X2C N 1.* N '
'| A:COUNT BYTES | EDIT PAD /0/ 1.* D2C RIGHT 2 N '
'| B:FANIN | JOINCONT // '
'| C:PPI SVOPEN | HOLE '
'¨ A: | B: '
'¨ C: | NLOCATE /+0000000000/ '
'| EDIT /PPI SEND FAILED, RC:/ NW 1.* NW '
'/(SEE "HELP PIPE PPI")/ NW | LOG NETLOG')
ROUTE(ONE NSPAUTO1));
Copy the NSPSVTAM member from prefix.NSPS210I.NSPSCLST to a NetView CLIST dataset (DISCLD).
The sample library (prefix.NSPS210I.NSPSSAMP) contains the following programs that you add to customize NetView:
Create the load modules (NSPVPPI, NSPMQS) by modifying and submitting the JCL in prefix.NSPS210I.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 you can 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, perform the steps listed in the following sections:
The data set members listed in Table 4-4 are located in prefix.NSPS210I.NSPSCLST and are used to change SOLVE:Netmaster for the mainframe application.
| Member | Description |
|---|---|
Describes the PROCs and how to implement the mainframe application. | |
Contains modifications to the SOLVE:Netmaster PPO procedure. | |
Contains the PROC that receives solicited and unsolicited VTAM messages and sends them to the mainframe application. | |
Contains the PROC that is the command PPI receiver (NSPNETV) and starts NSPKCM1. | |
Contains the PROC that is the command sender and receiver. |
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.NSPS210I.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.NSPS210I.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
When you complete all updates to SOLVE:Netmaster, you can issue the following command to verify correct installation:
SH PPIUSERS
The command displays two receivers, SNAVIEW and NSPNETV, and indicates the number of messages queued so you can monitor the number of messages that have been sent to the mainframe application.
Posted: Tue Sep 14 22:03:56 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.