Some Things to Think About:
Choosing Conferencing to Run on a Minicomputer
By Gordon Cook

[presented at the ENA Conference, Philadelphia, PA May '88]

Every situation is unique, therefore these suggestions are offered as guidelines in the hope that you will find them useful. They are not meant to be applied across the board in a mechanistic or rigid way. That is to say they are not meant to apply to every system or every situation. They come from being a conferencing user of EIES since 1980, Participate since 1986, and Caucus since 1986. They also come from over two years as a consultant to OTIS between 1985 and 1987 when I was involved full time with the development and evaluation of EIES 2.0. Finally they come from an evaluation of CoSy and Caucus under VMS at the John Von Neumann National Supercomputer Center during the final four months of 1987. These "guidelines" reflect my own experience and opinion and are not necessarily endorsed by the JVNC or Sterling Software ZeroOne Systems Group.

YOUR ENVIRONMENT

Begin by thinking at the most basic level: what RESOURCES do I have to bring to this endeavor? Am I looking for a tool, a utility that I can take off the shelf, plug in and run with little or no effort at the systems support level? Do I want conferencing to be a transparent means of communication and problem solving? Do I want to apply my efforts to solving problems that have nothing to do with conferencing per say?

OR...Do I want a product where I can get the source code and experiment with tailoring the product at the source code level?? Do I have the technical support that will allow me to deal with the system at the source code level? Am I interested in experimenting with conferencing as the end goal. Do I want to join the vendor in a mutual effort to improve the software? Am I primarily interested in the application as a means of offering a new means of communication to those who I serve? Therefore is my focus more likely to be on the PROCESS of communication than on the conferencing application as a tool to assist in solving of already identified problems?

The first environment should not demand an increase in your programing staff. The second environment almost certainly will.

If your programming resources are tight, ask questions designed to find out how much support at this level the product requires.

BEFORE THE SALE

Is the vendor willing to discuss your environment and proposed applications at a sufficient enough level of detail for you to make the wisest choice from the range of the products he offers? Or do you get the feeling that he'd like to sell you more than you need?

Remember that a sale does not mean that the product is being used six months or a year later. Therefore ascertain what kind of contact with current licensees the vendor is either willing or able to give. Is it the kind of free and uninhibited contact that allows for some depth of exchange?

And remember that on a mini computer there may be a wide gulf between the unsophisticated end user and the systems programmer who may be working quite hard to see that things go smoothly for the end user. Talk to those who support the product at the technical level. This could be the only way to assure yourself that you do have a plug-in-and-run product, if this rather than software R&D, is your goal.

PRICE:

Don't view the license fee as your only cost. Your true cost is the license fee PLUS whatever salary you have to pay for system programmer support to keep the application running.

AFTER THE SALE

Administrative support:

Will you need to write your own billing software if you will be charging users?

Will a system administrator have to add each user to the system, or if this is a new application on a system with existing users, can you post a headline telling users how they can add themselves?

If users are hit by line noise or a power interrupt and knocked off the system, can they log back on without having to have a system administrator reset their flags?

If you wish to modify a system feature or add a new one, can this be done by means of an operating system macro or must it be done by changes to the source code?

System Resource Demands

If you are to run on a dedicated machine, sizing your application so that you buy the right size machine can be a tricky question.

If, on the other hand you run on a machine with other applications, be careful, this is an application that can be very hardware hungry! Talk to the techiest techies you can find and ask lots of questions which may vary according to the operating system you are running under.

A few questions that occur are:

Program size: How many disk blocks needed for installation?

Memory requirements and usage: does the program use memory efficiently?

I/O; Does the structure of the program require unusually large numbers of disk reads and writes.

File structure: the program's file structure can impact both security and resource requirements. Is there anything about the file structure that can make it necessary for system administrators to raise normal user parameters such as the number of locks on files that a user may have in place at one time.?

SECURITY

Don't think of security JUST in terms of a password at log on. Realize that such questions as the level of file access privilege can cause problems on a system run with both captive and non captive accounts.

On a captive system make sure that it is not possible for a user to use an operating system specific editor to bring into his scratchpad a file that does not belong to him.

On a non captive system be sure that users do not have the ability to leave the application, go to the operating system prompt, take a directory of the conferencing system files, and do a type of any that look interesting.

USER FRIENDLINESS: Some Personal Opinions

Does the software force the user to be known by and sign his or her items with the system name which is usually a last name?

Does the software give the user the ability to start either a new conference or a new discussion item at will?

Can a user ascertain when another user last signed into the system?

Does the system send the user a receipt when his mail has been read by its recipient?

MINI or NOT to MINI?

In some cases, you will find that a mini computer is the ONLY way to go. You may however find it interesting to know that many of these issues disappear when you move to an AT or a 386 class super micro.

In this arena hardware and software support is much LESS complex and less expensive. PCAT clones have successfully supported several hundred regular users. A 386 PC should support somewhere between 1000 and 2000 users, depending on usage patterns.