Problem:

A Web-to-host mainframe session is assigned a model type when it is first created in the host wizard. When the session is loaded and connected, it doesn’t use the configured model type. For example, the session was configured as a model 5, but when it connects it negotiates a model 2. Why is this?

Resolution:

This symptom is often caused by an incorrect or inadvertently shared session configuration file. Web-to-host configuration files are located on the client PC in the %userprofile%\\My Documents\\NetManage\\Rumba\\Settings directory. The configuration filename for a specific session is its Session Name, with the suffix .cph added to the end. For example, if the session’s Session Name is “MyMainframeHost”, the associated configuration filename will be MyMainframeHost.cph. The Session Name is assigned to the session when it is created in the Web-to-Host Host Wizard utility. It appears on the Session Options tab:

var SessionID= "95871362";

var SourceName= "MyMainframeHost"; <<< This is the Session Name

var RedirectW2HServer= false;

To troubleshoot the incorrect model type issue, follow these steps:

1. Close the session that is exhibiting the problem.
2. Find the configuration file for the session (see above explanation).
3. Rename the configuration file from .cph to .bak, for example, from MyMainframeHost.cph to MyMainframeHost.bak
4. Reload the Web-to-host session.
5. The session should now load and use the correct model type, and a new configuration file will be created automatically.

This situation is commonly caused by two sessions sharing the same configuration file, but using different model type settings. To avoid this issue, make sure that all sessions have a Session Name that is unique. The following example illustrates how a conflict can occur when sessions share configuration files. Two sessions are configured, Session 1 and Session 2. Session 1 is configured as a model 2 display type. Session 2 is configured as a model 5. They’re both configured to use the same Session Name: “MF1”. Consider the following scenario:

1. Session 1 is loaded first. It checks to see if the configuration file “MF1.cph” is present. Since this is the first time it is loaded, the session configuration file doesn’t exist, so it is created.
2. Session 1 saves its model type (model 2) to the MF1.cph file.
3. Session 2 is now loaded. Since its Session Name is also “MF1”, it checks for a configuration file and finds “MF1.cph”.
4. Session 2 reads the configuration from MF1.cph, including the model 2 display type saved by Session 1 in step 2.
5. Session 2 connects to the mainframe as a model 2, even though the session was configured as a model 5.

In this case, Session 2 used the settings that were saved in the configuration file from Session 1, and they override the originally configured model type for the session. To prevent this, the sessions should be configured with unique Session Names, and hence would use unique configuration files to store their settings.

This article has described how to avoid incorrect model type usage by sessions inadvertently sharing configuration files.

“Incorrect model type” model mod
 

Date:
 
Name:
 
Description of change: 
Date:
 
Name:
 
Description of change: