Two issues of FYeI ago, I wrote that CUNY/CIS was moving towards the implementation of electronic mail based at our local area network, to replace use of CUNYVM for e-mail service. We are still moving in that direction. I would like to share with you some of the reasons why we have not yet reached our goal. It is our hope that documenting our project of migrating e-mail from one environment to another may be helpful to CUNY colleges that anticipate a similar move in the near future.

Infrastructure

At CUNY/CIS we have been totally networked since the mid-1970's, and we have had electronic mail capability since the early 1980's, when CUNYVM was installed. The network, however, was mainframe-based and our workstations were terminals that communicated well only with the mainframe. Therefore, to move e-mail to a LAN required us to create a totally new network: new wiring, new software with different protocols, and new workstations for all staff.

The process of deciding on the network architecture and hardware (we are using twisted pair, thick and thin coaxial cable and fiber), the software (Novell), and the workstations (various flavors) was the usual difficult one where technology is involved; making decisions is nerve-wracking when each new day brings new technology and better and cheaper ways of getting the job done! Nevertheless, we finally worked out the plan and a way to implement it. We still do not have workstations with adequate memory on the desks of all staff. And undoubtedly by the time we do, the memory requirements for minimum use of the network will have increased!

Decisions

In some ways it seemed to staff as if we were re-inventing the network we already had. CUNYVM was, and is, a mature system, providing reliable backup of data, good security, and simultaneous use by many of a single copy of applications. Now, we were being asked to provide these same services in our LAN environment as well. As I write this article we are still grappling with some of these issues:

• Network Software. We chose Novell 4.1. Choosing Novell was not difficult. Opting for the newly released version 4.1 was problematic, as noted below, but we had good reasons. Among them was the ability to extend our LAN beyond our physical location, so that communication with colleagues at CUNY's Central Office at E. 80th Street would be easy.

• Connectivity. There are software and hardware problems that must be resolved with each of the various flavors of microcomputers and workstations that we needed to connect to the network.

• Software licensing and use. We needed to learn the particular requirements of all site-licensed software to know how many copies to purchase for concurrent use on the LAN. We purchased a "polling" package, to help keep track of simultaneous use. Who needs to use what software? How do we make sure our staff is educated to appropriate use of the software? How much record-keeping must we do without being too intrusive? How can we budget the real costs associated with this kind of software usage?

• Data storage. What data should be kept on servers, and what should be kept on individual hard drives? How much disk space is enough on servers and individual desktop machines?

• Data backup. What data should be backed up? How often? By what process? Who should be responsible for backing up the server? individual hard drives?

• Hardware Maintenance. How to handle day-to-day maintenance on individual microcomputers, printers and other peripheral equipment? Are service contracts cost effective? How much down-time is acceptable for an individual staff member when a microcomputer fails?

• Software Maintenance. How to handle version updates? Keeping memory in desktop machines adequate for new versions of software. Compatibility of software with operating systems. Virus checking.

• System Administration and Security. Learning how to administer a Novell network was not trivial. Our staff is still learning (on-the-job, as well as by taking some formal courses).

• End User Training and Documentation. Staff who are expert in the CUNYVM environment now need training and manuals to learn how to negotiate within the LAN environment using microcomputer-based software.

• Staff Time. Since most CUNY/CIS staff have full-time assignments that are by and large mainframe-based, carving out the time necessary to learn about, plan and implement a LAN has been difficult and at times frustrating.

What about Electronic Mail?

I think staff who have been involved in this entire process would agree that choosing the e-mail package was the simplest part of the whole project. After making a few very basic decisions about the characteristics of our electronic mail configuration (LAN-based rather than Unix; "open" rather than "proprietary;" Internet-addressable), we were ready to investigate some possibilities. Early in the process we completed a fairly extensive review and testing of several popular LAN-based e-mail packages, optimistically assuming we would be ready for one soon.

Some of the features we investigated included: ease of installation, technical support, similarity to Rice Mail (the current CUNYVM mailer), the user interface, documentation, platform interfaces, file transfer capability, interface with the Internet, access to mail from home or elsewhere, ability to customize, cost, and most important, general functionality.

We chose Pegasus Mail. Although it is in the public domain, Pegasus is supported very well by its author, as well as by a wide and enthusiastic user community. Thus we felt confident that we would receive good support and that the package would continue to be upgraded in synch with upgrades to the environments in which it operates.

We purchased a university-wide site license for Pegasus documentation, which has been made available to the Site License Coordinators. Thus, other CUNY colleges can use Pegasus at no cost since the package itself is free. That seemed to us to be a valuable part of our decision.

The Big Problem

The tasks we have been working on, as described above, have not been the cause of the holdup in installing Pegasus and moving e-mail service for staff off CUNYVM. The decision to install Novell 4.1 (the latest version of the network software) is the culprit! The upgrade for Pegasus Mail, to allow it to operate in the Novell 4.1 environment, has been slower than we had hoped. This is a familiar problem to our staff, since compatibility between various layers of software has always been an issue in the mainframe environment as well. As of this writing our implementation date remains uncertain.

By the way, Pegasus is not the only software that is not ready to live harmoniously with Novell 4.1. It just happens to be the most crucial software within our project.

While We Are Waiting ...
More Decisions

When installing electronic mail, there are other things to be decided in addition to the e-mail package itself. One of the most important among them is what our e-mail addresses should look like. The goal is to be able to advertise a single point of entry, or mailhub, for all electronic mail addressed to staff at CUNY/CIS, regardless of what server the staff member is connected to. Then, for example, mail addressed to user@.cuny.edu would get re-directed to the appropriate destination.

Staff should be able to retrieve their mail from home (via dialup to the mail server), or from other platforms (e.g., CUNYVM, or Unix workstations), as well as when they are logged on to the LAN itself. There are several ways to accomplish this, and we must decide which protocol to use.

We need to decide where to store unread, queued mail, as well as mail that has been read, and how much disk space will be needed.

Security is a major issue, since our LAN is gatewayed to the Internet. We are in the process of implementing some "firewalling," so that we can control network traffic in and out of CUNYNet.

Sources of Help

Some CUNY colleges have long since gone through this process (see Marc Eichen's article "Hunter College Dials-Up to the Internet" in the Spring 1995 of FYeI, for example). Their experiences and resulting expertise have been very helpful.

We also looked to trade journals and magazines, mailing lists and Internet newsgroups, and to World Wide Web sites, for wisdom.

For very technical advice on Internet standards and security issues, there are numerous "RFCs" (Requests for Comment) that have been compiled and are available via Internet file transfer.

Conclusion

Despite the fact that it sometimes has seemed to us that we were "going back to start" in this process of moving from the mainframe environment to a LAN-based one, the end result will be worth the effort. Applications that are microcomputer-based tend to be more "friendly" than those that were written for large mainframe environments. Also, as a colleague recently described it, "Using CUNYVM for e-mail is like using a jet to fly from Newark to Kennedy"; providing e-mail service from a LAN is a better use of resources.

CUNY colleges that are anticipating making a similar move (either from campus-based mainframe electronic mail service or from CUNYVM mail to LAN-based mail) will have some of the same decisions to make as have been described above. However, it may be easier in some ways, and harder in others. Colleges, for example, have a more varied population of users. Requirements for student e-mail may be quite different from those for administrators and for faculty. The basic requirement of network accessibility will be easy for some campuses to fulfill, and most difficult for others.

There is a wealth of expertise within CUNY and beyond, and colleges that are beginning the process of providing electronic mail should utilize every avenue of help they can get. The result, for faculty, staff and students, will be well worth it.

Editor's Note:

Since this article was written the issue of what e-mail package to use has been re-opened for further consideration, punctuating Pat's comment that making decisions in the area of technology is difficult!