In Part 1 and Part 2 of the prior posts for this blog series on MCP Express (XE), I covered the basic installation of XE on a Windows 10 laptop. I also discussed how to deal with issues following an initial halt/load (boot) of the MCP operating system, start networking between the Windows and MCP environments, and access the MARC and CANDE user interfaces in a terminal emulator.

This post will continue the discussion on initial setup of the MCP environment, showing you how to tune the configuration of the ODT and MARC terminal emulator windows. It will also show you how to improve the usability of the ODT displays. Most of the topics in this post are applicable to all MCP systems, not just XE.

Quite a bit of the discussion in this post presents my personal preference for configuring the MCP user interfaces. I offer these to show some of the things that are possible and to give you some ideas on how you might want to configure these interfaces yourself. Unless I specifically mention that some setting or action is required, though, you can take the following as suggestions and recommendations, and alter or ignore them according to your taste.

Tuning the ODT Terminal Windows

The ODT and MARC terminal emulator windows provided by XE are implementations of the Unisys WebEnabler product, a Java-based application. Other terminal emulators can be used to access the communications interfaces, including MARC and CANDE, but the ODT interfaces require WebEnabler.

WebEnabler is a reasonably-featured emulator and is quite configurable. The configuration for each terminal instance is stored in a file with a .cfg extension. For the ODT 1, ODT 2, and MARC terminal instances created by the XE install, the configuration files are stored under C:\Program Files (x86)\Unisys\WebEnabler as ODT1.cfg, ODT2.cfg, and MARC.cfg, respectively. If you examine the properties of the corresponding Desktop icons, you can see the configuration file path being passed as a parameter to the WebEnabler program. These files are ordinary Windows text files consisting of name/value pairs for the configuration options. Here is a snippet from the configuration file for ODT 1:

ODTmode="true"
FontName="Lucida Console"
RegularTextSize="10"
RegularTextStyle="0"
BrightTextStyle="0"
BlinkTextStyle="0"
ReverseTextStyle="0"
BackgroundColor="0,0,153"
RegularTextColor="255,255,255"
BlinkTextColor="255,0,0"

You can change the configuration settings by modifying the .cfg files directly with a text editor, but it's usually easier and much safer to use the configuration editor built into WebEnabler. The configuration files created by the XE installation process can be read publicly. Because the files are stored under a Program Files folder, however, any program (including WebEnabler) wishing to modify them must be run with administrator privileges.

You can create additional configuration files for datacom and ODT windows and store them anywhere. If these are stored in a folder to which you have write access, you do not need administrator privileges to modify them.

We will start by modifying the ODT 1 configuration. It is best to work on ODT configurations with the MCP halted. Right-click the ODT 1 icon on the Desktop and select Run as administrator. The window will open and display the log-in credentials dialog. Cancel that dialog. Ignore any warnings at the bottom of the window about connection errors -- these are due to the MCP being in a halted state. On the window's menu bar, select File > Properties... A dialog box with five tabs will open.

Appearance Tab

The first tab on the Properties dialog controls the appearance of the emulator window -- primarily the font and colors:

I think the default ODT font and color settings are ugly, so this screen shot shows the ones I prefer. I chose Lucida Console 10 as the font, which I think is more legible and makes the window a bit smaller. The theme is basically white-on-blue, mimicking the ODT emulators from older MCP systems. It uses these specific colors:

I left the remaining color/style settings and other options on the Appearance tab at their defaults. Click Apply and then select the Advanced tab.

Advanced Tab

Be careful what you change on this tab, as it can affect operation of the ODT. In particular, do not change the Server Name, Socket Number, or Enable ODT Mode settings.

Requiring you to log on to the ODT window with your Windows credentials is both unnecessary and annoying. You can inhibit that by unticking the Use SSL checkbox.

You can change the cursor settings under the Display header on this tab if you wish, but I recommend that you leave the other settings on this tab at their defaults. Click Apply and then select the Keys tab.

Keys Tab

Many WebEnabler keystrokes are programmable. This tab shows the current key assignments and allows you to modify their behavior. Modifying this tab is entirely optional. It has three panes:

• Key - shows a pull-down list with all of the keystrokes that are programmable in WebEnabler. There are also checkboxes to indicate whether the keystroke is modified by the Shift and/or Control keys. Each unique combination of the Key, Shift, and Control selections has an associated "program," or macro, shown in the third pane below.
• Functions - shows all of the special functions that can be included in a key program.
• Program - shows the program associated with the currently-selected key and modifiers. The program consists of ordinary text, possibly interspersed with special functions within "<>" delimiters. If the program pane is empty (note that spaces are significant), the key performs its default function. See the WebEnabler Help for a description of these defaults.

You can use the key programming feature to modify the default behavior of the keyboard and provide convenience keystrokes.

For example, I do not like using Enter as the transmit key on the keyboard. The traditional key for that function (at least on U.S. keyboards) has been the large "+" key on the numeric keypad. Since I can change the default XE behavior to match my old habits, I did.

If you select the Enter key from the list in the Key pane, you will see that its default program is "<TRANSMIT>". I prefer the Enter key to work like a local new-line, so I changed its program to "<RETURN><CURSORDOWN>".  You can either double-click items in the Functions pane to paste them into the Program pane, or you can type the function names and their "<>" delimiters directly into the Program pane. Anything outside of the "<>" delimiters will be treated as literal text and copied into the terminal window when the programmed key is pressed.

Note that the default program for Shift-Enter is "<RETURN>". I also changed that to "<RETURN><CURSORDOWN>". The default for Ctrl-Enter is "<LINEXMIT>" (transmit the text on the current line from column 1 to the cursor), which I left as is.

Alas, these changes have left me without a way to perform a regular transmit. My minimalist laptop does not have a numeric keypad, nor an overlay for one on the regular keyboard, so following old habit, I used F12 as the transmit key and programmed it as "<TRANSMIT>". Also from old habit, I programmed Shift-F12 as "<LINEXMIT>".

The default key assignments for three other keyboard functions are not supported by my laptop, so I have programmed substitutes for them as follows:

As an example of programming keys for convenience, suppose I frequently want to know which programs in the mix are using the most processor time. The ODT command for that is "A SORT CPURATE" (active entries sorted by the current rate of CPU consumption). I could program that into a function key (say, F7) as follows:

<HOME><CLEAREOL>A SORT CPURATE<TRANSMIT>

This positions the cursor to the home position on the screen, clears from the cursor position to the end of the line, enters the command text onto the terminal window, and transmits it. Since this message fits on one line, I could have used <LINEXMIT> instead of <TRANSMIT>.

Advanced and About Tabs

The fourth tab on the Properties dialog, Advanced, allows you to set the interface language for WebEnabler, specify text encoding options for Asian languages, and specify character translation between the MCP host and WebEnabler. This tab can be ignored unless you are using a version of the MCP with non-U.S. conventions. The About tab simply displays version information for WebEnabler.

Wrapping up the ODT Configuration

When you have finished programming keys, click the OK button on the Properties dialog to close it. Back on the main WebEnabler window, which now has the new font, size, and colors you have chosen, there are two more configuration changes that cannot be made using the Properties dialog.

• You may have noticed earlier when running the MCP that text entry on the ODT window was operating in "insert" mode rather than "overwrite" move. I don't care for "insert" as the default mode. You can toggle it off simply by pressing the Insert key on your keyboard. The "insert" annunciator on the status line at the bottom of the window should disappear.
• I mentioned in the last post that the MARC window scrolls when you transmit, and that I don't care for that, either. Given the way the MCP normally formats messages for the ODT, these windows do not scroll, but that option is set by default in their configuration. You turn it off in a curious way -- press Home, then enter "?-S", and then press your transmit key (which is now whatever you may have changed it to on the Properties dialog). On older systems, this control sequence was acted on by the DCP (data communications front-end processor), but that device no longer exists. It is now detected locally by WebEnabler.

Both of these settings will be saved in the running configuration.

There is one final thing to do -- position the window where you would like it to be on your Desktop. The size and coordinates of the window are also stored in the running configuration.

Saving the ODT Terminal Configuration

All of the configuration changes, including the last two you made on the main window, are in WebEnabler's local running copy of the configuration and are active as long as this instance of WebEnabler continues to execute. Now we need to save the running configuration permanently on disk, which is the reason we ran WebEnabler this time "as administrator." On the menu bar, select File > Save. This will overwrite the ODT1.cfg file with the new settings. You could also select File > Save As... to save the changes in a different location, but you would then need to modify the shortcut on the Desktop (or create a new shortcut), passing the new configuration file name as a parameter to WebEnabler.

Now apply the same changes to the configuration for the ODT 2 window and save them as well. You may wish to define a different set of key programs, and will certainly want to position the window differently, but otherwise I recommend that you configure the two ODT windows identically.

If you need to change any properties of an ODT window instance later (including its position or key programming) and wish to preserve the new settings, simply run WebEnabler "as administrator," make the changes, and save them. For everyday use when you are not changing the configuration, just run WebEnabler normally.

Tuning the MARC Terminal Window

You modify the properties of the MARC terminal window in the same manner as for ODT windows. I prefer to give the MARC window somewhat different colors, however. Starting with the default color scheme, I changed only the window background color to a very light gray (RGB 238,238,238 = #EEEEEE), and the control text background to a light yellow (RGB 255,255,153 = #FFFF99).

On the Advanced tab, note that the Server Name is 192.168.16.5, the EVLAN IP address for the MCP environment. For the ODT windows, it was "localhost," meaning the Windows loopback address, 127.0.0.1. Be careful not to change the Server Name or Socket Number, but it is a good idea to enter a Station Name for emulator instances that will be used as datacom terminals instead of ODTs. This name will be passed to COMS and CANDE to identify the terminal instance. The name must be unique among the currently-attached stations, i.e., no two terminal instances may use the same name at the same time on the same MCP host.

You may specify an Initial Window name (e.g., CANDE) in the configuration if you wish. COMS "windows" are not like GUI windows -- instead, they map to an application or service. After you log on, COMS will switch you to that "window" automatically. If you leave the name blank, the MARC "window" is the default.

WebEnabler uses a custom protocol that by default connects over TCP/IP to port 3001 on the MCP side. This port is served by CCF, the COMS Custom Connect Facility. CCF converts the TCP connection to a COMS station instance, which allows COMS to treat the connection as a legacy datacom station. You can use WebEnabler from your XE installation to connect to other MCP systems as well, as long as they are configured to accept such CCF connections.

Tuning the MCP ODT Settings

The next task is to improve the layout and usefulness of the ODT displays. In order to do that, we need to start the MCP environment. As described in the prior post, start the MCP Firmware services from their system tray icon on the Windows task bar. Once all four services are running, start the MCP Console and load the MCP.

Open both ODT windows if they are not already open. You can open these windows either before or after you start the firmware service and load the MCP. This time you should not need to log in to the ODT windows, and you should see the new appearance you stored in their configuration files. You should also notice that both ODTs are displaying the same information, although they are probably refreshing at different times.

Check that the system time and date are valid (TD command) and change it if necessary (TR command). Once the time is acceptable, enter the TIMEOK command to dismiss the time-and-date waiting entry.

Automatic Display Mode

The first thing to change is the layout of the ODT displays so they are more useful. The formatting of the ODT windows is determined by a feature known as Automatic Display Mode, or ADM. The types of information displayed, order of presentation, and refresh rate can be set individually for each ODT. The MCP persists these settings and reinstates them after a halt/load.

ADM is controlled by the ADM ODT command. You can view the current settings by transmitting just "ADM". You should see a response similar to this:

ADM (ACTIVE 7, WAITING 3, SCHEDULED 2, COMPLETED 5, MESSAGES) DELAY 4

This says the ODT is to show seven lines of active entries, three lines of waiting (RSVP) entries, two lines of scheduled entries, five lines of the most recently completed tasks and jobs, with the remainder of the screen to show the most recently-displayed messages. This layout is to be refreshed every four seconds. If the amount of information currently available for a given category is greater than the number of lines allocated to it, the MCP will scroll through additional entries in that category at each refresh. Note that the number of lines specified in the ADM command includes the header line with the dashes, so the number of entries displayed is one less than the number of lines allocated in the ADM command. The display starts on the third line of the screen -- we will see why shortly and how that can be changed.

This is a reasonable default layout, but it has some issues. First, the four-second refresh rate is far too fast, making it hard to absorb the information before it is replaced. Both ODTs are displaying the exactly same information, which is pointless. Note that typically there are more than 100 active entries, so displaying those six at a time is also pointless. In addition, rapid refreshing of the ODTs can use a lot of processor time and impact the performance of both the system and user applications. Here is an ADM layout that I find far more useful. On ODT 1:

ADM (S2, W5, C) 15

I have used abbreviations above for the information categories -- two lines of scheduled entries, five lines of waiting entries, the remainder of the screen with completed task entries, refreshed every 15 seconds. On systems with a CD drive, I usually add "PER CD 2," after "W5," to display the label of any currently-mounted CD volume. On ODT 2:

ADM EVENT MSG, DELAY 15

This is a different form of ADM display. It specifies that the entire screen should be used for recently-displayed messages, most-recent first. "EVENT" specifies that the display will be refreshed only when new messages become available, but no more frequently than every 15 seconds. Waiting entries and messages are the two views you use the most to manage the system, so devoting a whole page to messages turns out to be a good idea.

The settings above represent my preference for ODT displays, honed through many years of experience with small MCP systems, but feel free to experiment and find an arrangement that suits you best. See the ADM command in the System Commands Reference manual for details on the types of information that can be displayed.

TERM Command

Several characteristics of ODT behavior can be modified using the TERM (Terminal) command. To view the current settings, transmit "TERM". You should see a response similar to this:

TERM LINES 24 WIDTH 80 FIRST 2 LANGUAGE ENGLISH CONVENTION * (ASERIESNATIVE)
TRUNCATE TRUE RESPONSE EXPANDED MESSAGES FALSE

LINES and WIDTH indicate the size of screen for which the MCP will format messages. You can, if you wish, change the size of the ODT window (on the Advanced tab of WebEnabler's Properties dialog) and then use the TERM command to tell the MCP the new size in terms of rows (lines) and columns (width).

FIRST specifies how many lines to skip at the top of the screen before the MCP starts formatting messages. The purpose of this parameter is to allow room for you to enter commands at the top without overwriting the messages that are displayed. Of course, a really long command may require more than two lines and overwrite displayed messages anyway, but commands that long are not that common. The default setting of "2" explains why the ADM entries start on the third line. You can change this if you wish, but two lines is a good value for normal use.

LANGUAGE and CONVENTION localize the ODT displays for a particular language and locale. You can change the language, but unless your copy of the MCP has been built with support for that language, messages will still display in English. The setting for CONVENTION affects the formatting of dates, numbers, etc. You can select one of the predefined conventions, e.g., EuropeanStandard, or define your own. See the MultiLingual System Administration, Operations, and Programming Guide for details.

TRUNCATE specifies whether messages will be limited to one line in length or allowed to wrap to multiple lines. The default value of TRUE is usually the best choice.

RESPONSE controls the verbosity of MCP responses to commands. It has options NONE, CONCISE, and EXPANDED. You will want to leave this at the default of EXPANDED.

MESSAGES controls whether individual messages are displayed on the ODT as they occur. These messages overwrite the top lines of the ADM display. Setting this parameter to TRUE is useful if you want to see messages immediately without waiting for an ADM refresh, but when a lot is happening on the system, the messages can come out too quickly to read. I like to set this option on ODT 2 where I have the ADM EVENT MESSAGES display, as it allows me to see things as they occur, but the ADM refresh will eventually show me everything, or at least the most recent screen-full.

TERM MSG TRUE

OP and SYSOPS Commands

The OP (Options) command specifies a set of Boolean options that control MCP behavior. You can view the current settings simply by transmitting "OP". You can read about these in the System Commands Reference, but the only one I would consider changing is #33, KEYEDIOII, which controls which version of ISAM (indexed file) should be used by default. If you don't do COBOL, you probably won't care, but I like to set this option:

OP+33

Another command that controls MCP behavior is SYSOPS. You can transmit a "SYSOPS" command to see the current settings and read about them in the System Commands Reference, but the default values are usually adequate for XE systems.

I strongly suggest that you not play with the settings for OP or SYSOPS unless you have read their documentation and understand the impact of changing an option. You can cause strange system behavior if you are not careful.

The final piece of ODT tuning we will discuss in this post is elimination of the annoying waiting entry for SYSTEM/ESR/ASSISTANT. This is a utility used to monitor the system and send Electronic Service Requests to Unisys. It is not supported on XE systems, which is why the waiting entry appears.

SYSTEM/ESR/ASSISTANT is configured as an Automatic Initiate program. This is a list of programs the MCP runs automatically after a halt/load. You can add your own programs to this list if you wish. To see the list, transmit an "AI" command on the ODT. You should see a response similar to this:

9 Auto Initiate Programs:                                                       
  AI CANDE              = *SYSTEM/CANDE ON DISK                                 
  AI MCPSERVERTCP       = *SYSTEM/MCPSERVER/TCPSERVER ON DISK                   
  AI HOSTMIB            = *SYSTEM/SNMPOBJMGR/HOSTMIB ON DISK 
  AI ESRASSISTANT       = *SYSTEM/ESR/ASSISTANT ON DISK                   
  AI COMS               = *SYSTEM/COMS ON DISK                                  
  AI NXPIPE             = *SYSTEM/NXPIPE ON DISK                                
  AI NXSERVICES         = *SYSTEM/NXSERVICES/SERVER ON DISK                     
  AI SOCKETROUTER       = *SYSTEM/SOCKETROUTER ON DISK                          
  AI SAFELIB            = *LOCUM/SAFELIB ON DISK

The programs are listed in no particular order. Note the fourth one in the list, "ESRASSISTANT". To delete it, enter this command on the ODT:

AI - ESRASSISTANT

That's all there is to it -- on subsequent halt/loads, the program will no longer run automatically, you will no longer see the waiting entry for it, and you will no longer need to enter an AX or DS command to dismiss the entry.

The next blog post will continue the discussion of things to be done after initially halt/loading your XE system. In particular, we will discuss how to connect to shared directories in the MCP from the Windows side of your workstation. After that, we will see that there are a number of utility programs available from the MCP that you can install on the Windows side to access and manage the MCP side.