Migrating to ArcInfo on WindowsNT

Overview

When Esri indicated that it planned to port ArcInfo to the WindowsNT environment, we began working toward moving our current application to utilize a WindowsNT client. This paper discusses what we have learned through our effort to port this application. It covers the hardware/software required, the application changes that were completed, and things to consider when dealing with ArcStorm.

Application Overview

Hardware

Software

Our next problem to be solved was making the UNIX file systems available to the WindowsNT workstations. This requires software on both the UNIX and WindowsNT machines. For both environments, there is freeware available to solve the problem. For the Sun environment, we chose to download pcnfs from the Internet. This software's main function is to provide authentication for the user on WindowsNT so that file permissions, etc. work correctly. On the WindowsNT machines, we chose to purchase software, since our network experts felt that the free software available generated too much network traffic.

The last piece of software to be addressed was our RDBMS, Oracle. Prior to this effort, most of our databases were running Oracle version 7.1.4. For ArcInfo 7.1.x we needed to be running at least Oracle version 7.2 and the current version is 7.3.x. Since we did not want to upgrade Oracle to anything other than the current version, Oracle 7.3.x was installed. The catch with this upgrade is that in Oracle 7.3.x, SQL*Net version 1 is no longer supported. While this did not cause our application any significant problems, we have seen other applications where this was a major problem. One other note is that the WindowsNT machines must also have access to SQL*Net V2 to function properly.

Application Changes

The other difference in path names between the two operating systems is the use of drive letters in WindowsNT. Although WindowsNT does support the use of a machine name in the path (\\) it is more common to use drive letter mapping (F:). This difference requires coding changes for the application to be sensitive to the environment in which processes are being executed. The area where this can be a particular problem is in the ArcStorm checkout or copyout process, since the client workstation setting up the checkout or copyout may be running on WindowsNT, but the actual execution of the checkout or copyout is running in the UNIX environment.

The area that required the most significant application changes were those places where system calls were being made (&sys). These calls fell into three general categories: 1) opening background processes, 2) execution of system commands (create/remove files and directories), and 3) executing scripts.

Opening background processes was not a significant problem since there is little difference between UNIX and WindowsNT in this area. However, we did look at each of these to determine if it were more appropriate for the process to execute on the server rather than on the client.

Likewise many of the UNIX system commands have an equivalent in WindowsNT. However, the command name is frequently different (rm versus del). At the very least, the location of the executable is different between UNIX and WindowsNT and in some cases the NT equivalent is not a standard part of the operating system. Rather than modify the application code to handle these differences, we chose to eliminate as many of these system calls as possible. While in some cases this had a small performance penalty, it had the advantage of improving the portability of the application and avoiding a lot of platform specific conditional statements. Much of what was being done with the system commands was directly achievable in AML. For example, rather than use a system call to create a new directory, the CREATEWORKSPACE command was used. In cases where the system call was used to create a "flag" file, it was necessary to open, write, and close the file in AML.

Execution of shell scripts proved to be the most difficult of the system calls to resolve. In a number of places in the application, system calls had been used to execute SQL*Plus, awk, and sed scripts. In many cases the SQL*Plus scripts were used to create temporary files with selected data from Oracle tables which were then used in scrolling windows within an AML form menu. This was an approach that was originally taken to get around the limit within an AML form menu that only INFO or flat files can be used to populate these scrolling lists. Another approach to getting around this problem is to create temporary INFO tables using the DBMSINFO function. This requires populating temporary tables in Oracle with the results of a query then creating the INFO table from the temporary table. This approach appears to have equivalent performance as the first approach as long as the selected set of records does not get excessively large.

ArcStorm Considerations

A related problem exists with the destination of the resulting coverage from a copyout or checkout action. Like the selection files, the original application wrote these coverages into workspaces in the user's home directory structure. This process was modified to always write the coverage to the UNIX file system then, at the user's option, copy the workspace to the client machine or leave it on the server. This requires the application to keep track of where the "real" coverage exists. One problem with this approach is that ArcStorm always considers the "real" coverage to be located in the directory where it was checked out. This can cause problems when resuming an ArcStorm transaction if the "real" coverage is not where ArcStorm expects it to be. However, for performance reasons, our application is designed to perform edits on a local coverage and display library features as background on demand.

The checkin process has the same considerations as the checkout process, so little additional work was required here. The primary change was to make sure the coverage or coverages were located where ArcStorm expected them to be.

Other Considerations - Forms and Windows

In an application like ours, a user may have many AML Form menus displayed on the screen at the same time. Some of the menus are intentionally placed by the application to overlap other menus in order to maximize the space available for graphic operations. This was not a problem in the UNIX environment, since the active window did not have to be "on top" of the nested windows. Under WindowsNT, however, the general mode of operation is that the active window is always on top. While this can be overridden by specifying that a specific window is "always on top", this gets awkward and confusing when multiple windows overlap each other.

Another problem comes from the difference in sizing and appearance of the windows. Under WindowsNT, the ArcInfo menus always have a status bar area at the bottom of the menu. This can cause the menu or form to be significantly larger in relative terms when compared to its UNIX counterpart. Further, icon and button placement that looked fine in UNIX takes on a different look and spacing in WindowsNT. In some cases, form menus that work fine under UNIX would not even fit on the screen under WindowsNT.

The real solution to these problems under ArcInfo on NT is to redesign forms and menus to minimize or eliminate overlapping windows. Additional effort must also be expended to review the appearance of every menu in the application to make sure that its appearance is acceptable in both environments. For an application like ours that contains hundreds of form menus, this can be a significant effort.

A less significant difference between the UNIX and WindowsNT environment is the screen resolution. On our Sun workstations, the normal display resolution is 1152x900, while many of our NT workstations are running a screen resolution of 1024x768. The main place where this causes a problem is when the application specifies an absolute location or size for a form menu. The best solution here seems to be the addition of logic to place and size menus based on the screen resolution.

Summary

While we did not perform any specific performance testing, we attributed the slower performance on WindowsNT to the difference between the performance of the processors and to our specific network configuration. We did notice improvements in performance as we moved more pieces of the application to the workstation (coverages, AML code).

It will be necessary to add NFS capability to the WindowsNT workstations. It may also be necessary to upgrade other software to more current releases in order to migrate an application.

Finally, any complex application will require time and money to migrate from UNIX to WindowsNT. The level of effort required will depend on UNIX specific code in the application, ArcStorm usage, and the number of form menus in the application.