|
|
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 and 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:
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 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:
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.NSPS301.NSPSSAMP(MODEENT). A sample of assembly and link-edit JCL is available in prefix.NSPS301.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:
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.NSPS301.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.NSPS301.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.NSPS301.NSPSSAMP) or JCL.
This task is necessary because SAS/C libraries are shipped in the SNA View load library, and the Cisco IOS stack and Interlink stack ship their own SAS/C copy of the LSCNCOM module, which replaces the copy shipped with the SAS/C library.
If you are using the Interlink stack, you must also supply the 4-character name of the Interlink stack in the NSPOPEN EXEC card in the NSPOPEN proc:
Where SUBS is the 4-character subsystem name for the Interlink TCP/IP stack.
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.
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.
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.NSPS301.NSPSSAMP) by using one of the following procedures:
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:
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:
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:
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:
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:
You would set the workstation parameters on workstation B as follows in the file
/etc/svopen_config_DOMAIN:
The host configuration files for workstations A and B each must have a TCP card that specifies the correct port configurations:
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:
After you add a new entry, you can use the following MVS command to dynamically reload the installation control specification (ICS) file:
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):
After you add the new entry, you can reload the program properties table immediately with the following MVS command:
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:
Step 5 Copy and modify the prefix.NSPS301.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 describes the Configuration Services exit routine and 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.
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.
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.
To determine if you have an active ISTEXCCS exit, issue the following command:
If 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:
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:
This 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 provided in this document 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.NSPS301.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:
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.
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.
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:
A minor exit routine always returns a 1-byte build vector that specifies the following:
These values are not returned to VTAM from minor exit routines. Instead, they are noted, checked for validity, and discarded. The NSP exit routine manager does not accept any other values from minor exit routines.
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.NSPS301.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.
Table 4-1 Parameters Card Values and Purpose
Use the EXCLUDE_SW_MAJNODES parameter card to specify a list of SNA switched major nodes whose PUs and LUs will be excluded from discovery and monitoring.
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.
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.
You can include more than one EXCLUDE_SW_MAJNODES parameter card.
EXCLUDE_SW_MAJNODES NODE1 ... NODEn
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.
To have the application exclude all PUs and LUs associated with the SNA switched major nodes SWDOM1 and SWDOM2, code the following parameter card:
Use the INCLUDE_PU4 parameter card to specify a list of SNA PU 4 major nodes (these are NCP names local to this mainframe) that will be monitored for PU 4-PU 4 connections.
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.NSPS301.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):
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.
You can include more than one INCLUDE_PU4 parameter card.
INCLUDE_PU4 [NODE1 [... NODEn]]
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.
The examples are based on this sample configuration on mainframe HOST1:
The following examples show how to use search patterns:
To monitor all PU 4-PU 4 connections for NCP1A and NCP2C, use this card:
To monitor all PU 4-PU 4 connections for all NCPs with names that begin with the characters NCP1 or NCP2 use this card:
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:
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*.
Use the INCLUDE_SW_MAJNODES parameter card to specify one or more SNA switched major node names whose PUs and LUs will be included in the discovery and monitoring.
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.
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.
You can include more than one INCLUDE_SW_MAJNODES parameter card.
INCLUDE_SW_MAJNODES NODE1 ... NODEn
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.
To have the application include all PUs and LUs associated with the SWDOM1 and SWDOM2 switched major nodes, code the following parameter card:
Use the LU_CONTROL parameter card to specify how LUs should be discovered and monitored. This card provides important information required to properly obtain initial status and maintain the status of VTAM resources defined to NSPOPEN.
If you do not include an LU_CONTROL parameter card, the CONSISTENT option is the default.
You can include only one LU_CONTROL parameter card.
OPTION specifies how LU names are selected for discovery and monitoring. The following options are available:
For example, the following PUs and LUs would be defined in such a way to allow the CONSISTENT option to be applied.
The previous PU_LU_FILTERS could be combined to the following filter:
The consistent option is the preferred option because it reduces processing on the host. In a consistent environment, the number of PULU_FILTERS is usually much lower than required for an UNIQUE environment.
When status information flows from VTAM to NSPOPEN, it is in the form of VTAM display messages. These messages do not always indicate the type of resource involved (PU versus LU). In a consistent environment, a single PU_LU_FILTER can control one or more physical units and the associated logical units.
Consider the following example using a different naming convention:
This example shows a clear mapping between the PUs name and the associated logical units. However, a single PULU_FILTER cannot be used for both the LUs and PUs.
When the CONSISTENT option is specified, additional host processing is saved because once a physical unit passes the PULU_FILTERS, the associated logical units are considered to have passed the filter.
It is important to note that incorrectly specifying CONSISTENT for LU_CONTROL for an environment that is inconsistent can cause the status to not flow for certain logical units.
To have the application discover LUs based on a consistent PU and LU naming convention, code the following parameter:
The following filters would be specified for the
To have the application discover LUs based on a unique PU and LU naming convention, code the following parameter:
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. 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.
Use the MSG_LEVEL parameter card to specify whether warning messages are displayed.
If you do not supply a MSG_LEVEL parameter card, ERROR is used.
You can include only one MSG_LEVEL parameter card.
Use the ONLY_SWITCHED_PUS parameter card to specify whether the application will discover all PUs and LUs, or just the PUs and LUs associated with SNA switched major nodes.
|
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. |
YES is the default: the mainframe application will discover and monitor only PUs and LUs associated with SNA switched major nodes.
You can include only one ONLY_SWITCHED_PUS parameter card.
{YES | NO} specifies whether the application will discover and monitor only PUs and LUs associated with an SNA switched major node.
To have the application discover and monitor only PUs and LUs associated with an SNA switched major node, code the following parameter card:
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. |
If no parameter is specified then no PRELOADS are performed.
You can include several PRELOAD parameter cards. Only one load module name is allowed on each preload statement.
To preload load module L$CALMTO, code the following parameter card:
Use the PULU_FILTER parameter card to specify, by name, which PUs and LUs will be discovered and monitored, and which will not be discovered or monitored. Because this card filters PUs and LUs by name, name your PUs and LUs with a common naming convention. You can include a series of PULU_FILTER parameter cards.
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.
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.
You can include several PULU_FILTER parameter cards.
PULU_FILTER [-]FILTER_TOKEN1 . . . [-]FILTER_TOKENn
[-] 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:
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:
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:
Use the TCP_LEVEL card to identify whether you are running the IBM TCP/IP V3R4 (or later) protocol stack.
If you do not supply a TCP_LEVEL parameter card, BASE is used.
You can include only one TCP_LEVEL parameter card.
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.
Table 4-2 Required Subtask Parameter Cards
The DISCOVER parameter card specifies the name of a VTAM APPL definition to be used for the discover subtask.
You must supply a DISCOVER parameter card; NSPDSC1 is the default value.
You can include only one DISCOVER parameter card.
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.NSPS301.NSPSSAMP(NSPAPPL) member, the sample discovery VTAM APPL is named NSPDSC1.
If the ID of the discover subtask's APPL definition, coded with AUTH=SPO, is NSPDSC1, you would code the following DISCOVER parameter card:
The MVS parameter card specifies the name of the extended MCS mainframe console to be defined for receipt of MVS messages. You define this name for the application workstation to receive MVS messages. The MVS parameter card is required so the mainframe application will be notified if the VSAM data set is changed from the primary data set to the backup data set. In a Sysplex environment, console messages are retrieved from the local system only.
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.
You can include only one MVS parameter card.
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.
To specify NSPCONS1 as the extended MCS console, use the following MVS parameter card:
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.
You must supply a PPI or PPO parameter card.
You can include only one PPI parameter card.
To connect the application to the NetView or SOLVE:Netmaster PPI for receiving VTAM messages at the workstation, code the following PPI parameter card:
|
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. |
You must supply a PPI or PPO parameter card.
You can include only one PPO parameter card.
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.
If the ID of the APPL definition coded with AUTH=PPO is NSPPPO1, code the following PPO parameter card:
Use the SEC parameter card to specify the security clearance level needed to activate and deactivate SNA resources from the workstation.
If you do not supply an SEC parameter card, BLOCK is used.
You can include only one SEC parameter card.
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.
To prevent workstation users from issuing mainframe commands, use the following parameter card:
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.
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.
You can include up to ten SERVER parameter cards, one for each workstation attached using LU 6.2.
SERVER plu slu PARALLEL NSPOPNMS NSPOPNCS
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.
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:
The STATUS parameter card specifies a VTAM APPL definition that will update the status of SNA PUs and LUs.
None. The STATUS card is required.
You can include one STATUS parameter card.
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.NSPS301.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.
If the ID of the status program's APPL definition, coded with AUTH=SPO, is NSPSTA1, code the following parameter card:
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. |
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.
You can include up to 20 TCP parameter cards (1 for each workstation attached using TCP/IP).
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.
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:
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 |
|---|---|---|
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.
If you do not supply an SPO parameter card, users cannot activate and deactivate SNA resources from a workstation.
You can include only one SPO parameter card.
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.NSPS301.NSPSSAMP(NSPAPPL) member, the sample SPO VTAM APPL is named NSPSPO1.
If the ID of the APPL definition coded with AUTH=SPO is NSPSPO1, code the SPO parameter card:
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:
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 2.
You might also need to define the Operator ID to the security product.
Step 2 Define a profile for the new NetView autotask (defined as NSPAUTO1 in Step 1) by adding a member named NSPPROF to your NetView's DSIPRF data set. NSPPROF must contain the following three lines:
You can change the member name to conform to your site requirements, but it must match the PROFILEN statement that was coded in Step 1.
Step 3 Add the following line to your initial command list to ensure that the new NetView autotask (NSPAUTO1) is started each time NetView is started:
Step 4 Copy the NSPSVTBL member from prefix.NSPS301.NSPSAMP to a NetView DSIPARM data set. Add an include for NSPSVTBL in the current automation table member (%INCLUDE NSPSVTBL).
|
Note The following two steps are only for users of NetView Version 2.3 or earlier. Unless you are running NetView Version 2.3 or earlier, skip these steps. |
Step 5 Define the mainframe optional task by adding the following definition to the DSIDMN member of your NetView's DSIPARM data set:
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 6 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:
Copy the NSPSVTAM member from prefix.NSPS301.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:
The sample library (prefix.NSPS301.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.NSPS301.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.NSPS301.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.NSPS301.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.NSPS301.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:
|
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:
The 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: Fri Jun 20 08:30:12 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.