| Install Remote IMS Server | Configure the Mainframe | |
This chapter provides an overview of installing and configuring your PC communications product. It starts with a description of the CPI-C Side File.
The Remote IMS Requester uses the CPI-C interface and requires a Side File to be created. This Side File contains the same information for all communications products.
After the section on the Side File there is a section for each communications product. These sections give an overview of the Side File configuration. They also describe other product-specific issues and may provide additional suggestions for their use with Remote IMS.
The Remote IMS Requester uses the CPI-C interface for LU 6.2 communications. The advantage of using CPI-C is that it simplifies the programming and communications setup.
There is no communications configuration required in the Requester program. All of the communications parameters are defined within the communications product. Logically, this begins with the CPI-C Side File.
Some products may call the Side File a Symbolic Destination Name. When you create a Side File you give it a symbolic name. This name is the only value from your communications product configuration that the Requester must know. The Side File name must match the name provided in the rmtims.ini file's "CpicSideFile" setting. The sample rmtims.ini file uses a name of remotedb.
When the Requester initializes the LU 6.2 conversation, it makes a call to the communications product passing it the CpicSideFile name. From this, the communications product uses the name to determine the Partner LU, Mode-names, destination TP Name, security information and any other information it requires.
The basic information provided in the Side File is listed in the following table:
| Side File Information |
Description |
|---|---|
| Partner LU | This is the LU-name defined for your IMS/ESA system for LU 6.2 support. This LU is defined by the APPC/MVS "LUADD" statement. The LU-name is defined in the ACBNAME keyword of the LUADD statement. For example, ACBNAME(IMSLU62). This LU-name is also defined in VTAM. The Partner LU is a "qualified" name which means you prefix the LU-name with the network-name. The network-name is defined in your VTAM definitions. An example of a fully-qualified Partner LU is NET1.IMSLU62. See the chapter Configure the Mainframe for an example LUADD definition for APPC/MVS. |
| Partner TP-name | The Transaction Program-name specified on the PC must match the name defined in APPC/MVS for the Remote IMS Server. Any name can be used - as long as they are the same. You can choose a name to suit your company's naming standards. In the example shown in the chapter Configure the Mainframe, the TP-name is MFDBTPN. |
| Mode-name | A number of mode-names are provided with the communications products. You must choose a mode-name that is available on the target VTAM system where the Remote IMS Server runs. You choose a mode based on your company's requirements for network routing, performance and other factors. Any mode can be used with the Remote IMS Requester. A "#INTER" mode is provided by most PC communication products as a default for interactive applications. |
| Security | The usual choices for
security are None, Same and Program. In general, you can choose None. A
setting of None does not send a user ID or password to the mainframe. If
your mainframe requires a user ID and password, it rejects the
conversation due to an authorization failure. The Requester detects this
failure and prompts you for a user ID and password. It retries the
conversation by setting the security option to Program with the user ID
and password you specify in its popup.
Additional information about security is provided in the product-specific topics which follow. Also, see the section Security Handling - User ID and Password in the chapter Advanced Requester Configuration. Remote IMS does not require any specific security setting. You can select any value to suit your company's requirements. Remote IMS simply watches for authorization failures and prompts you for a user ID and password if one occurs. You can choose to terminate the conversation from this popup instead of providing a user ID and password. |
Installing and configuring Microsoft SNA Server consists of two main steps. These are:
Microsoft's SNA Server is a client-server based SNA product. The main component of SNA Server is installed on an NT Server machine. The definition of your SNA features and connections is performed on this server.
The main things you define are:
The connections are the physical and logical links from the NT Server to your mainframe. See your SNA Server documentation for complete information.
There are a variety of techniques for defining LUs for LU 6.2. These are called APPC LUs in SNA Server. There are default LUs and specific LUs. The specific LUs can be assigned to individual user IDs or placed into pools. You should arrange the LUs to suit your requirements. If Remote IMS is your first LU 6.2 application on SNA Server, it is probably easiest to create your APPC LU as a member of the "Default Outgoing Local APPC LU Pool". This can minimize the amount of initial LU configuration required by Remote IMS. When you have successfully connected to the mainframe you can arrange your APPC LUs to suit your permanent requirements.
The CPI-C Side File is also defined on the SNA Server. Each Remote IMS client references this same Side File entry. You should create the Side File according to the instructions in the section CPI-C Side File described earlier.
Care should be taken when setting "Conversation Security", in the CPI-C Side File, to "Program" as this setting takes the user ID and password you specify in its popup. As the CPI-C Side File entries are shared by each SNA client connecting to this SNA Server, each person uses this user ID and password when connecting to your mainframe.
For this reason, we recommend using the Requester's security features where the Requester prompts you for a user ID and password only when needed. To do this, set the CPI-C Conversation Security type to "None".
You can configure the Requester to allow you to save your user ID and password. You can store these values in a disk file or in memory. See the section Security Handling - User ID and Password in the chapter Advanced Requester Configuration for a complete description of the Requester security handling.
SNA Server uses software running on each Windows client to provide the end-to-end connection required by Remote IMS. The SNA Client component is installed on each Windows client which uses the SNA facilities defined on an SNA Server.
The Remote IMS Requester makes calls to the SNA client software. The client software communicates to its SNA Server. The SNA Server, in turn, communicates with the IMS/ESA mainframe. See your SNA Server documentation for client installation instructions.
The CPI-C interface used by the Requester was intended to operate across many different vendor's products.
However, some vendor's products require product-specific calls which are unique to a specific vendor's implementation. For example, Microsoft's SNA Server requires special "startup" and "cleanup" calls. In other cases product-specific calls were necessary for some versions of a product or as a work-around for areas in a vendor's product which do not comply with CPI-C level 2 specifications. Recently, the CPI-C level 2 specification has been more widely adopted by leading communications product vendors. This is more complete than the CPI-C level 1 specification and can, hopefully, provide the product independence originally intended.
The Generic communications product support in the Requester is based on the CPI-C level 2 specification. It means the Requester performs its work using only those calls (APIs) which are defined in the CPI-C level 2 specification. No additional calls are made and none can be required.
For a list of other requirements for Generic support, see the section Requester Software Requirements in the chapter Requirements. The built-in communications product support has advantages over the Generic support. With the built-in products, the Requester uses product-specific calls or exploits a product's behavior to improve performance, minimize memory overhead and provide easier use and other benefits. However, the lack of these extra features does not materially reduce the Requester's functionality.
Configuring a product for Generic support is very similar to any of the built-in products. The only definition the Requester uses is the CPI-C Side File. See the section CPI-C Side File earlier in this chapter for details. Any other definitions required for communications are transparent to the Requester, for example, the physical and/or logical links between the client and the mainframe.
For general information about configuration in addition to the CPI-C Side File, you can review the configuration instructions in this chapter for our built-in support. Although specific instructions vary between products, general issues are often similar between products. If your communications product has some client software with centralized server software, the Microsoft SNA Server instructions may be helpful.
We recommend using the Requester security unless you find a reason to use an alternative technique.
To use the Requester's security handling, set the CPI-C Side File's Conversation Security Type to "None". Basically, this means the Requester prompts you for a user ID and password when needed. You can configure the Requester to save your user ID and password. These values can be stored in a disk file or in memory. See the section Security Handling - User ID and Password in the chapter Advanced Requester Configuration for a complete description of the Requester security handling.
There are two rmtims.ini settings which are different than the typical settings for the built-in products.
One is the "WhenStopTP" setting. The sample rmtims.ini has this set to "Idle". For Generic products this must be set to "Never". For an explanation of this setting see the section Rmtims.ini Settings in the chapter Advanced Requester Configuration.
You also need to add a setting in rmtims.ini for the "CommsDLLname". This setting names the dll which contains the CPI-C function calls. Each vendor is likely to have their own name and location for this dll. The Requester must know its name so it can load the dll before making any CPI-C calls. See your communication product's documentation for this name. See the section Rmtims.ini Settings in the chapter Advanced Requester Configuration for instructions on setting this value. You may be able to determine this dll name without referring to your vendor's documentation. This dll generally contains "CPIC" somewhere in its name. For example, wincpic.dll, wcpic.dll, wcpic32.dll, cpic32.dll and so on. You can look for this dll in the product's installed folder. On Windows, this dll may also be in the Windows system folder.
Copyright © 1999 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.
| Install Remote IMS Server | Configure the Mainframe | |