Thus far in this series on MCP Express, we have been setting up and using the MCP environment in an isolated mode. The MCP is able to communicate via TCP/IP internally with the local Windows environment and vice versa, but it is not yet capable of communicating on an external TCP/IP network. Configuring the MCP environment to work with an external network is the subject of this post.

As we will see, configuring TCP/IP for the MCP is quite a bit different than it is on most other systems. In fact, it's a little weird. You may have noticed some of this when following the directions in Section 3 of the MCP Express Getting Started Guide under the heading "Setting the MCP Host Name." The reason for the weirdness is historical, so I will start with a review of that history.

History

The original concept for mainframe communications was host-centric. All terminal devices connected directly to a single host, and all message traffic went through that host. Remember that this started when most organizations had only one computer system, terminals were dumb, and network circuits were even dumber. These were the days of RS-232, teletypes, and (for Burroughs systems) poll-select terminals like the TD800 series.

By the mid-1980s, Ethernet, LANs, and the precursors to the Internet were beginning to stand this host-centric approach to communications on its head. First the "Network Architectures" (e.g., SNA for IBM and BNA for Burroughs) turned the star-shaped mainframe networks into networks of stars, then smart terminals, PCs, and modern networking protocols got rid of the stars (i.e., the role of the mainframe as a central node) altogether and everything connected directly to a common network. The Internet is simply an extension of that trend, a network of networks.

BNA, the CP2000, and the NAU

The first implementation of TCP/IP for the MCP was a component of BNA (Burroughs Network Architecture) and ran inside a traffic concentrator/front-end processor known as the CP2000. An MCP system connected to a local CP2000 over an Ethernet LAN. The connection on the MCP side was handled by an I/O adapter known as the Inter-Connect Processor, or ICP -- a term still used today on MCP systems to refer generically to a host network adapter.

CP2000s could be connected with each other over local or wide-area links using BNA, and with other systems using protocols such as SNA and X.25. They could also serve as remote terminal controllers, for example, hosting multiple poll-select circuits and multiplexing the data onto a long-distance link back to one or more mainframe hosts.

The hosts and CP2000s of a BNA network are configured using a series of "initialization" or "INIT" files. These are simply card-image text files, usually of type SEQDATA on MCP systems. They have a free-form notation that is used to define network entities and the attributes of those entities. In a full BNA network with lots of hosts and CP2000s, there could be a lot of these files and a lot of cross references among them -- so many that there is an administrative tool, the NAU (Network Administrative Utility), to help create the files and maintain the relationships among them.

The NAU is a program with a MARC-like menu interface, backed by a DMSII data base. You use screen menus and forms to specify the network configuration, which is stored in the data base. When you have completed your definition of the network, or an update to that definition, the NAU extracts the configuration from the data base and creates the necessary INIT files, which can then be distributed over the network to the various nodes.

Fortunately, configuring TCP/IP for the MCP requires only two INIT files, and both are fairly simple. If you need only TCP/IP and none of the other BNA facilities, it is usually easier to ignore the NAU and maintain the INIT files manually. That is the approach I'll describe in this post.

Host-Resident TCP/IP and CNS

Having TCP/IP as part of BNA and running in the CP2000 must have seemed like a good idea at the time, because the CP2000 had a lot of infrastructure for networking and protocol conversion. There were two problems, though. First, the CP2000 was a fairly expensive device, and if all you wanted to do was TCP/IP, it was not a cost-competitive solution. Second, the CP2000 had a limited amount of memory, and thus could support only a limited number of TCP socket connections at a time -- a couple of hundred at most.

The problems with CP2000 cost and capacity prompted Unisys to completely redesign TCP/IP in the early 1990s and implement it within the MCP environment, providing a lot more memory for maintaining socket state and eliminating the need for the expensive CP2000. An ICP was still needed to connect to the external network, and TCP/IP was still part of BNA. That meant that the configuration and management components of BNA were still used for TCP/IP, and the configuration was done in BNA terms, not commonly-accepted TCP/IP terms. This initial orientation of TCP/IP to BNA is the source of the weirdness.

By the late 1990s, use of TCP/IP had spread widely throughout the installed base of MCP systems, and a lot of sites were using TCP/IP without any of the other BNA components. At that point, Unisys decided to split TCP/IP off from BNA. As part of that effort, it split the low-level management and control functions of BNA that both BNA and TCP/IP depend upon into a separate facility known as CNS (Core Networking Services). CNS provides the networking interface to the I/O subsystem and network adapters. BNA and TCP/IP then subscribe to CNS services for physical transmission and reception of data, and implement their protocols on top of the services that CNS provides. Thus, while TCP/IP is no longer dependent upon BNA, it is dependent upon CNS.

Hence the reason for needing two INIT files for TCP/IP -- one is for the CNS configuration and one is for the TCP/IP configuration. If you are also running BNA, then the CNS file will have additional entries to support BNA, and you will need additional INIT files to configure the BNA components.

Emulated MCP Systems and Shared Network Adapters

In 1996, Unisys introduced the first MCP systems where the architecture was emulated on Intel Pentium processors running Microsoft Windows. As part of that emulation, Unisys started using commodity PC network interface cards (NICs) rather than its proprietary ICPs. In this environment, a piece of Unisys software known as Janus sits between the commodity NIC driver and the Windows networking stack. Janus serves as a software router between the NIC, Windows, and the MCP. It allows both the MCP and Windows environments to share the same NIC and its connection to an external network. The MCP term for this arrangement is a "shared adapter." The software package that includes Janus and supports MCP use of commodity NICs is known as ClearPath Network Services or NX/Net.

This approach of using commodity NICs has become prominent, and is now used for all MCP systems. There is always some sort of Windows environment that drives the NICs, either an embedded computer appliance on older systems, a utility partition on the newer systems, or the host Windows system on the low end of the product line -- the NX4200, LX, Libra 300/400 series systems, and the MCP Software Series systems. That last is also the arrangement that MCP Express uses.

The final piece of background is that Unisys recently introduced an entirely new implementation of TCP/IP, known as TCPv3, which breaks further away from the BNA roots. This new implementation has an entirely different system of configuration and management. It is presently available only on systems that implement the I/O Architecture (IOA) -- currently the latest Libra 4000, 6000, and 8000-series. It cannot be used with MCP Express, so for our purposes you can ignore any references to it.

Prepare for External Networking

To prepare MCP Express for external networking, there a few requirements that must be met.

First, you will need to assign at least one static IP address for the MCP environment on your local subnet. Your host Windows environment likely has a dynamic IP address assigned through the Dynamic Host Control Protocol (DHCP), which it can continue to use. The MCP Express environment, however must use static IP addresses. You may see references to DHCP in the MCP networking documentation, but as with TCPv3, this is presently available only for Libra 4000, 6000, and 8000-series systems. The easiest thing for most home and small office networks is simply to pick an address outside the range your local subnet's router has set aside for DHCP and assign that address to the MCP.

Second, you must use IPv4. The MCP has support for IPv6, but this is not available in MCP Express. You will recall that a warning for a missing IPv6 key appears on the ODT after a halt/load. One of the things we will do as part of configuring external networking is suppress that warning.

Third, you will need to use a wired connection to your local subnet. MCP Express does not support wireless adapters.

When MCP Express was installed, a utility named the NIC Configuration Manager was also installed, and an icon for it placed on your Windows Desktop. This utility is used primarily to establish adapter teams (multiple physical network adapters working in parallel as one virtual adapter) and is normally not required with MCP Express. You can ignore this utility and delete its icon from the Desktop if you wish.

Enable a Network Adapter

To enable a network adapter for MCP use with an external network, the emulated hardware configuration (the Peripheral Configuration Diagram or PCD) for MCP Express needs to be modified. That means you need to modify the active PCD, which means using the System Editor, which in turn means the MCP environment cannot be running. If it is, shut it down, either by entering POWER OFF SYSTEM on the ODT or by clicking the Halt button on the toolbar of MCP Console. Then click the System Editor button on the toolbar of MCP Console.

Inside System Editor, click the Active button on its toolbar to open the currently-active PCD. If System Editor displays a dialog box to adjust resources, check to see if your network adapter is being added, and if so accept that change. Normally, though, you should just cancel that dialog. In the left-hand pane of the System Editor window, you should see something similar to this:

The "NP" nodes refer to emulated Network Processors. Note under the NP 210 node there is a Line 0 node that is ticked, indicating it is part of the current configuration. Line 0 represents the adapter for the internal EVLAN that was configured automatically when MCP Express was installed. Also note under the NP (with no number) node there is a node labeled Line 1, and possibly nodes labeled Line 2 and Line 3. If you click those nodes, information about them will appear in the right-hand pane. The important things to examine in the right-hand pane are the "Connection Name" and "Display Name" entries. From that, you should be able to determine if the node is for a wired (Ethernet) adapter, a wireless adapter, or perhaps one for Bluetooth.

On my laptop, as shown above, Line 1 is the wired Ethernet adapter -- GBE stands for Gigabit Ethernet. On another one of my systems, Line 2 is the wired adapter. This can vary from system to system, so examine the properties of each line carefully. Next, using your mouse, select the node for the wired adapter and drag it onto the NP 210 node. Then tick the box next to that adapter node. You will note that this causes three of the properties for that adapter to change:

• Adapter Sharing changes from "N/A" to "Not Shared." Click on that property value and select "Windows Shared" from its pull-down list. This setting allows Windows and the MCP to share the same physical adapter. If you have multiple wired adapters on your system, you can optionally leave this setting at "Not Shared" on one of them, meaning the MCP will have exclusive use of that network interface and it will be unavailable to Windows. Windows will then need to use some other adapter.
• NP Number changed from 0 to 210.
• Usage changed from "NonMCPUse" to "MCPUse."

Also note the value of the "Line ID" property. It is usually a 1 or a 2. We will need that number when preparing the CNS INIT file. On my laptop, the result now looks like this:

While we are in System Editor, recall that after a halt/load you have seen waiting entries on the ODT similar to "SC3 is not connected to CHAN 20103." This is because SC 3 and SC 4 are enabled in the PCD, but we do not have WebStation ODT windows running for them. You probably do not need more than two ODT windows, so the easiest way to eliminate those waiting entries for good is to untick the boxes next to the SC 3 and SC 4 nodes on the PCD, removing them from the active configuration. You can also untick the corresponding Channel nodes, but that is not necessary.

The next step is to save the new configuration. I strongly recommend that you do a Save As... and give the updated PCD file a different name. This will allow you to fall back to the prior configuration in case there is a problem. I like to put the date in the PCD file name. On the dialog box where you save the file, there is a text box where you can enter a comment describing the reason for the configuration change.

Once the PCD is saved, click the Set Active button on the System Editor toolbar to make this the active PCD. Then close System Editor.

Load the MCP

The next steps require the MCP, so click the Load button on the MCP Console toolbar and open the ODT windows. If after the load you get a waiting entry on the ODT similar to this:

 2506/ 2506 80 3:50 Job DISPLAY_CONFIG_ERRORS
CONFIGURATION PERIPHERAL ERRORS FOUND DURING INITIALIZATION

enter a <mix>Y command on the ODT (e.g., 2506Y) to see the reason. If the response contains a line similar to this:

Display: **ERROR** SC 3-4: NOT AVAILABLE FOR USE

then the error is due to removing SC 3 and SC 4 from the PCD. This is benign, and the MCP is simply reporting that it formerly had these units in its configuration but they are no longer present. Enter <mix>OK to dismiss the message. The MCP will adjust its record of available peripheral devices, and you should not see this message again.

Update the CNS INIT File

The next step is to assure the configuration in the CNS INIT file aligns with the new PCD. Open the MARC window, sign on with the administrator account, and switch to CANDE. Refer to Section 3 of the MCP Express Getting Started Guide under the heading "Setting the MCP Host Name" for details if necessary. If you would rather use PWB or the ClearPath Visual IDE to edit the files, feel free to do so.

On the ODT, enter the command NW CNS. You should see a response similar to this:

CNS is available 
NEXT INIT/INFO FILE WILL BE CLEARPATH/INIT/CNS.

This tells you the name of the current INIT file for CNS, i.e., the one that will be used the next time CNS is initialized. Open this file in CANDE or your editor. Ignoring the large comments at the front and back of the file, lines 3100-7200 should look similar to this:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
%  Host Attributes
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
NW AUTHORIZE *DEFAULT                               = NETWORKCONTROL;% 
NW AUTHORIZE ADMINISTRATOR AT MCPHP14               = SECURITY;% 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
%  Add Connection Group for NX/Network Services NP 210 Line 0
%  This group is for EVLAN.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
NW ADD CONNECTIONGROUP CG_ICP_2100%
   %   Connection Group Information 
       (  TYPE                      = LAN% <
        , ICPDEVICEID               = 210% 
        , LINEMODULEID              = 1% 
        , LINEID                    = 0% 
        , SPEED                     = 100000000% 
        , LOCALADDRESS              = *DEFAULT% 
        , MAXINPUTMESSAGESIZELIMIT  = 4352% 
        , MAXOUTPUTMESSAGESIZELIMIT = 4352% 
        , MAXINPUTMESSAGESIZE       = 4352% 
        , MAXOUTPUTMESSAGESIZE      = 4352% 
       )% 
;% 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%  Add Connection Group for NX/Network Services NP 210 Line 2
%  This group is for an MCP connection to the site's corporate LAN.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
NW ADD CONNECTIONGROUP CG_ICP_2102% 
   %   Connection Group Information 
       (  TYPE                      = LAN% 
        , ICPDEVICEID               = 210% 
        , LINEMODULEID              = 1% 
        , LINEID                    = 2% 
        , SPEED                     = 1000000000% 
        , LOCALADDRESS              = *DEFAULT% 
        , ADAPTERTYPE               = GIGABIT% 
        , MAXINPUTMESSAGESIZELIMIT  = 1500% 
        , MAXOUTPUTMESSAGESIZELIMIT = 1500% 
        , MAXINPUTMESSAGESIZE       = 1500% 
        , MAXOUTPUTMESSAGESIZE      = 1500% 
       )% <
;%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%  End Initialization
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
NW CNS ENDINIT;%

This is the running CNS configuration for your system. The attribute values specified in this file are critical to both TCP/IP and the network adapters working properly, so you should not change them other than specified below unless you really know what you are doing. The NW commands are described in the Networking Commands and Inquiries Help document. The networking entities and attributes used in those commands are described in the Networking Attributes Data Dictionary Help document.

MCP networking operates using tables in memory. The ODT commands that begin with NW establish and manipulate these tables. The INIT files for CNS and TCP/IP are nothing more than scripts of these commands to create an initial configuration. You can modify many elements of the running configuration dynamically by entering NW commands on the ODT, but the running configuration (including the configuration initially loaded from INIT files) is lost whenever the system is halt/loaded or the networking software is restarted. The INIT files are simply the way the system automatically establishes an initial configuration when networking is initialized.

You should have already updated the NW AUTHORIZE command at line 3500 when you initially set up MCP Express. You may delete the large blocks of comments (lines beginning with "%") at the start and end of the file if you wish, but be sure to preserve the NW CNS ENDINIT; command at the end of the file.

You may have noticed that most of the lines have a "%" comment delimiter as the last non-blank character on the line. These are an artifact of the way the NAU generates the files, and the trailing "%" characters are not necessary. They were probably there originally to decrease the parsing overhead when INIT files were loaded by CP2000s, but that overhead is negligible on MCP systems. You may delete the trailing "%" characters if you wish.

For the purpose of TCP/IP networking, the only thing the CNS INIT file does is create CONNECTIONGROUP entities. In BNA terms, a CONNECTIONGROUP is equivalent to a physical communications circuit or line. For example, a poll-select circuit would have been represented as a CONNECTIONGROUP and all of the stations connected to one circuit would have belonged to the same group. In modern networking terms, a CONNECTIONGROUP represents a network adapter. Thus, the commands in this file define the physical (or in the case of the EVLAN, virtual) network connections to the system.

A CONNECTIONGROUP is distinguished by the ICPDEVICEID (NP unit number) and LINEID attributes. These must match the corresponding values for an NP and Line ID in the PCD. MCP Express systems typically have only one NP/ICP device, numbered by convention as 210. LINEID 0 is always reserved for the internal EVLAN connection between the Windows and MCP environments on the host system. Physical LAN connections are always numbered starting at 1.

Notice that the first CONNECTIONGROUP in the INIT file is for LINEID 0, and is thus for the EVLAN. Therefore, the second group will be the one for your external network adapter.

Carefully check the correspondence between the Line ID you noted for the adapter you added to the PCD with the LINEID attribute in the second CONNECTIONGROUP. If they are the same, you are done and no further changes to the file are necessary. If they are different, change the value in the INIT file to match that in the PCD. You should also change the name of the CONNECTIONGROUP to match, as discussed next.

There is an optional change to this file that I would recommend, if only to make things a little easier to understand and remember. The CONNECTIONGROUP names are of the pattern CG_ICP_nnnl, where nnn is the NP/ICP number and l is the LINEID. This is another artifact of the way the NAU generates INIT files. For a simple configuration like this one, I like to name these using the pattern NPnnn_LINEl. To me, that makes more sense and is easier to remember, especially when we get to the TCP/IP configuration.

Using my naming pattern, the first group in the file above would be named NP210_LINE0 and the second one would be NP210_LINE2. Whatever naming convention you choose, if you change the LINEID attribute, you should also change the CONNECTIONGROUP name to match.

If you have made changes to the CNS INIT file, save the file. As with the PCD files, it is a good idea to save changes to the configuration under a different file name so that you can fall back to the prior version in case something goes wrong. Once again, I like to put the date in these file names. In CANDE, since these files usually reside under the global (*) directory, you will need to use a command similar to:

SAVE AS *INIT/CLEARPATH/CNS/20190415 OVERRIDE

The OVERRIDE option allows you to save a file with the same name as one that already exists. The existing file will be replaced. Of course, you can save files into the global directory only if you have privileges to do so, which is why these configuration edits should be done under a privileged usercode such as ADMINISTRATOR.

My preference is to use the MCP host name as the first node of networking configuration file names, and save files in this form:

SAVE AS *MCPHP14/INIT/CNS/20190415 OVERRIDE

This completes the changes to the CNS INIT file. The final file I prepared for my system looks like this: MCPHP14.INIT.CNS.20190429.sqd_m.

Update the TCP/IP INIT File

The TCP/IP INIT file is modified in a manner similar to the CNS file. The most important things that need to be done for TCP/IP are:

1. Setting the correct IP address and mask for your local subnet.
2. Setting the default TCP/IP host name.
3. Adding TCP/IP CONNECTION entities to the CNS CONNECTIONGROUP entities.
4. Defining a default route so that the MCP will be able to communicate outside your local subnet.

On the ODT, enter the command NW TCPIP. You should see a response similar to the following, showing the name of the current file:

TCPIP is available                                                              NEXT INIT/INFO FILE WILL BE CLEARPATH/INIT/TCPIP.

Open the specified file in CANDE or your editor. Ignoring most the comment lines in the file, it should look similar to this:

%%%   NW TCPIP OPTION + IPV4ONLYOPERATION;%
 NW TCPIP TCPIPIDENTITY ADD NP 210 LINE 0%
            192.168.16.5/30 VISIBLE -;%
 NW TCPIP TCPIPIDENTITY ADD NP 210 LINE 2%
            192.168.237.50/24 VISIBLE +;%
 NW TCPIP TCPIPHOSTNAME MCPHP14.DIGM.COM;%
 NW TCPIP OPTION - USERFCMTU;%
 NW ADD CONNECTION TO CG_ICP_2100%
           2100_TCPIP_2100%
    %   Connection Information                                          
           (  NETWORKLAYERENTITY         = IP%
            , REMOTEADDRESS              = 000000000000%
            , CLASS                      = CLASS_1%
            , FRAMETRACE                 = FALSE%
            , RETRYLIMITXID              = 10%
            , MAXINPUTMESSAGESIZELIMIT   = 4352%
            , MAXOUTPUTMESSAGESIZELIMIT  = 4352%
            , MAXINPUTMESSAGESIZE        = 4352%
            , MAXOUTPUTMESSAGESIZE       = 4352%
           )%
 ;%
 NW ADD CONNECTION TO CG_ICP_2102%
           2102_TCPIP_2102%
    %   Connection Information                                          %
           (  NETWORKLAYERENTITY         = IP%
            , REMOTEADDRESS              = 000000000000%
            , CLASS                      = ETHIP%
            , FRAMETRACE                 = FALSE%
            , RETRYLIMITXID              = 10%
            , MAXINPUTMESSAGESIZELIMIT   = 1500%
            , MAXOUTPUTMESSAGESIZELIMIT  = 1500%
            , MAXINPUTMESSAGESIZE        = 1500%
            , MAXOUTPUTMESSAGESIZE       = 1500%
           )%
 ;%
 %%%NW TCPIP ROUTE ADD DEFAULT 192.168.237.250 %
 %%%   PREF 1;%

You will need to make several changes and additions to this file to prepare it for your local network.

1. The  NW TCPIP OPTION + IPV4ONLYOPERATION;% command shown near the front of the file is commented out. If you uncomment it by removing the leading "%" characters, this will set that option and instruct the TCP/IP software that it is to enable only the IPv4 protocol. That will eliminate the annoying waiting entry for the missing IPv6 key that appears after a halt/load. Note that setting or resetting this option must be the first command in the INIT file. Also note that for this command (and this TCP/IP command only), the semicolon (;) must be followed by a "%" character, otherwise a syntax error will occur. Thus, if you choose to remove the trailing "%" from the lines in the file, this "%" must remain in place. That odd requirement is probably a result of special checking for the presence of this command at the start of the file.
2. The TCPIPIDENTITY (or IDENTITY or ID) commands assign IP addresses and network masks to network adapters. A single adapter may be assigned up to 32 addresses.
   • IP address 192.168.16.5 is the address for the internal EVLAN. The settings for this adapter should not be changed.
   • The 192.168.237.50/24 address and mask is the default for the external subnet, which you will need to change to the static address you have chosen for MCP use and the network mask for your local subnet. On my network, it would be 192.168.152.172/24.
   • The LINE attribute must match the Line ID for the adapater in the PCD and the LINEID attribute for the CONNECTIONGROUP in the CNS INIT file. If you changed the CNS LINEID, you will need to change it here as well to match.
   • The VISIBLE attribute controls the visibility of IP addresses to MCP software. It should be "-" for the EVLAN and "+" for external connections.
3. The TCPIPHOSTNAME (or TCPIPHN) command specifies the default TCP/IP host name for the system. You may have already modified this command when first configuring TCP/IP for internal networking. This is in the usual DNS format as one or more names delimited by periods (.). Each name node must begin and end with a letter or digit, but internally a name may also contain "-" and "_" characters. Maximum total length is 63 characters. Unisys recommends that the first node of this name match the host name for the system specified by the ODT HN command. The remaining nodes should match the domain name for your subnet, if any.
4. The OPTION - USERFCMTU command suppresses enforcement of the RFC 1122 Maximum Transmission Unit (MTU), which restricts packets to 536 bytes. With this option reset, TCP/IP will use the maximum transmission size configured for the connection, typically 1500 bytes for Ethernet subnets. You should leave this option set only if devices on your network are constrained to use the RFC MTU size.
5. The ADD CONNECTION commands enable TCP/IP on specific CONNECTIONGROUPs that were previously defined in the CNS INIT file. The syntax is ADD CONNECTION TO <group name> <connection name>. As in CNS, the funky names are due to the way the NAU generates INIT files. The pattern is nnnl_TCPIP_nnnl, where nnn is the NP number and l is the LINEID. I prefer a naming convention of TCPIP_NPnnn_LINEl. You should not normally change any of the attributes for these connections, but make sure that the CONNECTIONGROUP names match those in the CNS INIT file.
6. The ROUTE command at the end of the example above is commented out, but unless you are planning to have the MCP communicate only on your local subnet, you will need to uncomment this and modify it. The ROUTE command is used to establish static routes for MCP TCP/IP. In this case, you will use it to establish a default route. This is the destination to which the MCP will send any traffic that it does not know how to route. This traffic will be destined for a different network, so normally you need to route it to the gateway router on your local subnet.
   
   • Change the IP address in the command to that of your router. Do not specify a network mask.
   • The PREF attribute specifies the relative priority of this default route with respect to any other default routes that have been specified. Lower numbers are higher priority. Specifying a preference of 1 is okay if you have only one router, but that makes dynamically adding a higher-priority route difficult later should that become necessary. I usually specify the preference as 10 or 20.

Optional TCP/IP Configuration

With the changes above the TCP/IP INIT file should be usable, but I like to add a few more settings to improve robustness and efficiency. You may skip this entire section if you wish. These settings are intended for small, simple networks where the MCP environment is relatively static. You may wish to change or eliminate some of these, and all of them are optional. There are quite a few more settings available like this, which you can read about in the TCP/IP Implementation and Operations Guide. The settings can go anywhere in the file.

NW TCPIP MAPPING + DIGMHP14 192.168.16.6;
NW TCPIP MAPPING + MCPD83A  192.168.152.170;
NW TCPIP MAPPING + MCP7520  192.168.152.175;

NW TCPIP OPTION - USERFCACKSTRATEGY;
NW TCPIP OPTION + ISSUEICMPRESET;
NW TCPIP OPTION - LANRESIL;
NW TCPIP OPTION - WAITFORHN;
NW TCPIP OPTION + CACHELEARNEDMAP;
NW TCPIP OPTION + UPDATEYHBYLEARNED;
NW TCPIP OPTION + DYNAMICPORTFILTER;
NW TCPIP OPTION - SSL;
NW TCPIP BROADCASTFILTER DISABLE;
NW TCPIP DYNAMICINIT DISABLE UDP ALL;
NW TCPIP DYNAMICINIT DISABLE TCP ALL;

NW SNMP SET TCPMAXCONNECTIONS = 1024;
NW SNMP SET IPFORWARDING = DISABLED; 
NW SNMP SET RIPENABLED = DISABLED;
NW SNMP SET ICMPLIMITEDBCAST = DISABLED;
NW SNMP SET ICMPRDISCPERFORM 192.168.152.171 = DISABLED;
NW SNMP SET IPMASKCONFIG 192.168.152.171 = STATIC;

The MAPPING commands map a host name to an IP address. Collectively, they act like a "hosts" file in Windows or Linux, allowing MCP applications to address external servers by name rather than IP address. A host name may have multiple addresses. We will discuss in a later post how to set up DNS name resolution for the MCP so that it can connect to an external DNS server.

One useful thing is to include a MAPPING command for the Windows EVLAN address, as shown in the first command above. This allows MCP applications to connect easily to the Windows side of your system over the EVLAN, which is more efficient than connecting using an external network address. Additional MAPPING commands may be added for other hosts in your subnet or on the Internet.

The OPTION commands do the following:

• -USERFCACKSTRATEGY -- RFC 1122 requires that a sender force a receiving system to send an ACK after at least every two MTUs of data. Resetting this option improves performance. This option is reset by default, but it is good to document the setting in the configuration.
• +ISSUEICMPRESET causes the MCP to use RFC 1122 rules for handling ICMP packets. Resetting this option enables security features in the MCP that can help protect against ICMP attacks. For MCP Express on a small network, you probably do not need that. The option is enabled by default.
• -LANRESIL turns off the LAN Resiliency feature of MCP TCP/IP. This allows TCP dialogs to be transferred to another connection in case of an adapter failure. There is overhead to setting up such dialogs, and it's another thing you probably do not need with MCP Express. This option is set by default.
• -WAITFORHN disables the wait for resolving the host name of the remote system when opening a dialog. This usually allows dialogs opened by MCP applications to be available to the application more quickly. The downside is that the port file attributes YOURHOST and YOURDOMAINNAME may not have useful values until the resolution completes some time later. The default for this option is reset.
• +CACHELEARNEDMAP causes the MCP to add entries to the memory-resident mapping table (as if NW TCPIP MAPPING ADD commands had been done) when the MCP learns of a mapping between a host name and an IP address. The default for this option is reset.
• +DYNAMICPORTFILTER causes the Network Services software running on the Windows side of the system to trap and discard incoming packets addressed to a socket. This eliminates the overhead of the MCP having to reject the packet. The default for this option is set.
• -SSL disables SSL/TLS support in TCP/IP. Unless you are actually planning to configure and use SSL/TLS for MCP connections, this option should be reset. The default for this option is reset.
• -SSH disables Secure Shell support in TCP/IP. As with SSL, unless you are planning to use SSH, this option should be reset. The default for this option is reset.

BROADCASTFILTER DISABLE turns off filtering for broadcast packets, something you probably do not need to worry about with MCP Express.

DYNAMICINIT DISABLE inhibits the ability for incoming TCP and UDP packets to initiate certain system services if they are not currently running. For example, by default, an incoming packet for port 80 will initiate the MCP web server. Disabling dynamic initialization prevents that from happening and reduces the overhead in the handling of incoming packets. One downside of this is that it may prevent MCP services such as PWB (NX/Edit) from initiating automatically. They can be initiated manually using an NA ODT command, e.g., NA NXEDIT+.

There are several TCP/IP-related options that can be set through the SNMP interface:

• TCPMAXCONNECTIONS specifies the maximum number of socket connections that can be in use at any one time. I set this to 1024 or so on small systems. The system limit is 65K.
• IPFORDWARDING controls whether MCP TCP/IP will route packets between adapters for different networks on the same system. Normally you don't want to use the MCP system as a router, and if you have only one adapter it cannot happen anyway, so I always disable this.
• RIPENABLED controls whether the Routing Information Protocol (RIP) is active for the MCP. This is seldom needed on a small local network, so I usually disable this as well.
• ICMPLIMITEDBCAST should be set to prevent possible flooding of the network when a link using router discovery is configured with a broadcast address and you have routers that retransmit limited broadcast messages. This is seldom an issue on small networks, but it is a good idea to set this option anyway.
• ICMPRDISCPERFORM controls whether the MCP will send router discovery solicitation messages. This is another feature that is seldom needed on small networks. The IP address in the command is that of your external adapter, as specified in the TCPIPIDENTITY command.
• IPMASKCONFIG set to STATIC inhibits the MCP from exchanging network mask information with other hosts on the network. The IP address in this command is also that of your external adapter. This is yet another feature that is seldom needed on small networks.

After completing the necessary changes to the file, carefully check your work, as networking will be down shortly and correcting errors is difficult without access to CANDE or an MCP editor. When ready, save the TCP/IP INIT file as you did for the CNS file, preferably under a different name than the original TCP/IP file, e.g.,

SAVE AS *MCPHP14/INIT/TCPIP/20190429 OVERRIDE

This completes our initial configuration for external networking. The final TCP/IP INIT file for my system looks like this: MCPHP14.INIT.TCPIP.20190429.sqd_m.

Implement the New Configuration

Now that you have INIT files customized for your system and subnet, you need to establish those files as the running configuration. There are three steps to this:

1. Specify the files as the new configuration.
2. Shut down TCP/IP and CNS.
3. Restart CNS and TCP/IP.

Steps 2 and 3 can be accomplished simply by doing a halt/load, but it will be useful for you to know how to stop and restart the networking providers gracefully. When doing all of the steps, numbers 1 and 2 can be done in either order.

Recall from above that we determined the current name of the CNS INIT file by entering a NW CNS command on the ODT. A variant of this command is used to designate a new file. Using the file with my naming convention, it would be:

NW CNS = *MCPHP14/INIT/CNS/20190429 ON DISK

I recommend that you specify the file title with a leading "*" to indicate the file resides in the global directory. I also recommend you specify the family name at the end (e.g., ON DISK). Similarly, the new TCP/IP file can be specified using my naming convention as this:

NW TCPIP = *MCPHP14/INIT/TCPIP/20190429 ON DISK

These new settings will take effect the next time that networking is started. They also will be remembered across a networking restart or a halt/load.

Next, initiate shutdown of TCP/IP with the following command. Note that this will disconnect any MARC, CANDE, or PWB connections you may be using and abort any associated sessions.

NW TCPIP-

You will see a few of the networking services show up in the Waiting Entries on the ODT, along with messages similar to these:

NW 15:45 DUE TO NLE REQUEST 
NW 15:45 TO IP 
NW 15:45 CONNECTION CLOSED FOR CONNECTION 2100_TCPIP_2100 
NW 15:44 PHASE CHANGED FOR TCPIP FROM NETWORKING TO TERMINATING

Wait a few seconds until you see an EOJ in Completed Entries for the job STOP/TCPIP, then initiate shutdown of CNS:

NW CNS-

You will then see quite a few more messages display. Wait until you see an EOJ in Completed Entries for the job STOP/CNS. This may take about a minute. Networking is now completely shut down. To restart it, make sure you have specified the new INIT file names, then enter these commands on the ODT:

NW CNS+
NW TCPIP+

You can enter these commands one after the other without waiting between them. The MCP networking software will parse the respective INIT files and load their configuration. Keep an eye out for messages and Waiting Entries indicating there is a syntax or semantic error in the files. You can get more information about an error by entering <mix>Y, using the mix number of the waiting task entry. If an error occurs, shut down the affected provider with a "-" command, correct and save the file, then restart the provider with a "+" command.

Correcting an error at this point is a bit problematic, as networking is not yet operational, so you will not be able to use the MARC window on your desktop or another editor, such as PWB. One option would be to shut down both providers, switch back to the original configuration files, and restart networking the way it was originally, but that can be tedious.

Another approach is to use the MARC interface that is built into the ODT. To do that, enter a ??MARC command on one of the ODTs. It will stop working as an ODT and should display a MARC log-on form. Log on with your administrator usercode and password, switch to CANDE as you would for a regular terminal and make the necessary corrections to the file in error. After saving the file, transmit the command ??ODT, which will switch the window back to ODT mode. The MARC session will continue to run in the background, and you can continue to switch modes using the ??MARC and ??ODT commands.

If CNS and TCP/IP initialize cleanly, the initialization process should complete with a series of messages similar to the following (shown most-recent-first as they would be on the ODT):

* 3761 16:40 NAMESERVER:Announcing to 192.168.152.172/192.168.152.255 
* 3761 16:40 NAMESERVER:Datagram port opened successfully 
* 3761 16:40 NAMESERVER:Registration successful 
* 3761 16:40 NAMESERVER:Registering via BMODE (no viable WINS server exists)... 
* 3761 16:40 NAMESERVER:Initialization complete 
* 3761 16:40 NAMESERVER:NameServer port opened successfully 
* 3761 16:40 NAMESERVER:IP addr/subnet 192.168.152.172/255.255.255.000 
* 3761 16:40 NAMESERVER:Using domain name PARADIGM 
3761 16:40 NAMESERVER:Using host name MCPHP14 
NW 16:40 TO IP 
NW 16:40 CONNECTION OPENED FOR CONNECTION TCPIP_NP210_LINE1 
NW 16:40 CONNECTION INITIATED FOR CONNECTION TCPIP_NP210_LINE1 TO IP

As a first test, try pinging the Windows side of the system from the ODT to make sure that still works:

NW TCPIP PING 192.168.16.6

Then try pinging some known IP address on your local subnet, such as the address for your router, e.g.,

NW TCPIP PING 192.168.152.1

Also try pinging the MCP from the Windows side of the system, and if you can, ping the MCP's external IP address from some other system on your local subnet. If all that works, then external networking is functioning properly. Note that you will not be able to ping DNS host names from the MCP just yet, unless you have included them in NW TCPIP MAPPING commands in the TCP/IP INIT file. The additional setup to support DNS resolution will be covered in a future post.

If you uncommented the NW TCPIP OPTION + IPV4ONLYOPERATION command in the TCP/IP INIT file, you should also notice that the warning about a missing IPv6 key now no longer appears.

Troubleshooting

Problems with getting TCP/IP networking set up and running have been one of the most common issues for MCP Express I have seen over the past two years in posts on the comp.sys.unisys newsgroup. One of the motivations behind starting this blog has been the frustrations people have had with MCP Express networking . Hopefully the discussion and details in this post will help you in the future, but there is no guarantee that everyone is going to get it right the first time. If you have tried to follow the instructions in this series of blogs and are still having problems with networking, this section will give you some things to try.

1. Make sure you are on the latest Windows updates. For Windows 10, this is especially important. There were significant changes in "Feature Update to Windows 10, version 1809," which started rolling out in October 2018 and recently received a cumulative update, so make sure that is installed. I will note, though, that my Win10 Home laptop is running version 1803, and I have not had any problems.
2. Carefully review using System Editor that the NP Line attributes in the PCD (NP number and Line ID) match the corresponding ICPDEVICEID and LINEID in the CNS INIT file.
3. Carefully review that the CONNECTIONGROUP names in your TCP/IP INIT file match those in the CNS INIT file.
4. Check all other changes you made in the INIT files, especially the IP addresses and subnet masks.
5. On Windows 7, I have had problems in the past with the "Unisys Network Services Protocol Driver #1" component not being selected in Windows for the external network adapter. From the Windows Control Panel, select Network and Internet and then select Network Connections. Right-click on the Ethernet adapter, select Properties, and verify that the Unisys driver is ticked.
6. If you can ping from Windows to the MCP over the EVLAN (192.168.16.5) but not from the MCP to Windows (192.168.16.6), check the Network Category in the Network Connections applet mentioned above. You can also see this on the Network and Sharing Center applet. The MCP adapter will probably show as "Unidentified network" and as a Public network rather than a Private, Home, or Work network. If it shows as Public, try this:
   • Run Windows Powershell as an administrator.
   • Enter this command:
     Set-NetConnectionProfile -InterfaceAlias "<EVLAN name>" -NetworkCategory Private
     where <EVLAN name> is the name of the network connection with the Device Name "Unisys Network Services EVLAN TCP Adapter." This is often "Local Area Connection 3" on Windows 7 and "Ethernet 3" on Windows 10.
   • Refresh the Network Connections or Network and Sharing Center applet to see if the Network Category has changed.
7. If nothing else works, it may be time to try uninstalling and reinstalling MCP Express. I recommend that you do this only as a last resort. You will need to do a full uninstall (chose the "Programs and Data" option when uninstalling using MIM), which will delete the contents of MCP family DISK. Thus, you need to save everything you want to keep from the disk unit and restore it later. As an alternative, you can save and reinstate the entire disk:
   • Make sure you have sufficient disk space on your Windows system -- at least 20GB, because for a short time it will need to have space for two copies of the logical disk file for family DISK.
   • Make sure the MCP environment is completely shut down.
   • In the directory you set up for MCP logical disks when you installed MCP Express, change the name of the file diskxxx.asd to something else. It can keep the .asd extension.
   • Now fully uninstall MCP Express, selecting Programs and Data during the Uninstall – Remove Options dialog. Since you changed the name of your logical disk file, it will not be removed.
   • Reboot your Windows system.
   • Reinstall MCP Express, following the instructions in the ClearPath MCP Express Getting Started Guide and earlier posts in this blog series.
   • After installation, but before starting the firmware services or halt/loading the MCP, remove the new diskxxx.asd file created by the install and rename the former file back to diskxxx.exe.
   • Now start the firmware services and load the MCP. All of your former files should still be in place.

In the next blog post in this series, we will continue working with the connection to an external network, configuring some additional TCP/IP features of the MCP.