[net.micro.mac] Tops for the PC and Mac

naftoli@aecom.UUCP (Robert N. Berlinger) (08/29/86)

We recently received TOPS in the mail and I am rather disappointed.  To me, 
networking software should be transparent, simple, and most important of 
all, robust.  TOPS just isn't tops!  

Actually, the Mac version is much nicer than the DOS version (do tell!).  
You install a DA, some drivers, and an INIT using an installation program 
that they furnish.  Reboot your Macs, and voila, you are up and running.  
You can mount volumes as Read Only, One Writer Only, or Many Writers, and 
you can have password protection as well.  The programs use the simple 
PUBLISH and MOUNT scheme -- the server publishes whatever disks or 
individual HFS folders to be available on the network, and the client can 
then view and mount whatever is published.  

So far so good.  

My real problem with it is that it isn't robust.  For instance, if the 
server or client crashes, TOPS doesn't seem to register that, and either 
thinks it is still talking or just hangs.  

Also, some very common actions can bring down the server as far as the 
network is concerned.  Since TOPS runs as what Centram calles a "hidden 
DA", it will stop functioning if you go into the minifinder!  Although this 
is mentioned in the manual, I think this is a rediculous restriction.  

Copying files on the server brings clients to a grinding halt, and 
formatting any floppy (although you get a warning) will kill off any 
clients you have.  

Although the following problems aren't really Centrams fault, they are 
issues that have to be dealt with in terms of networks in general.  

1.  The Finder was never meant to be used with multiple users per disk.  
    Problems like trashing desktop files (happens often since there is only 
    one for all those simultaneous users!), files put in the trash showing 
    until empty trash is executed, etc.  make life difficult.  
   
2.  Copy protected programs don't like to run over the network.  In fact, 
    at least one which I tried (Fontographer with its heavy protection, damn 
    them) crashed the client system altogether.  
   
3.  Lots of programs don't like to run from write protected volumes because 
    they need to create temp files.  In addition, a lot of these programs 
    create temp files that don't have unique names, so they crash if two 
    people use them at once from the same folder.  
   
Now on to the PC end.  

Although TOPS is supposed make the differences between OSs seem 
transparent, it doesn't do a very good job of it.  It does a pretty good 
job with handling the file naming issue (DOS is 8.3 with no blanks, Mac is 
31 with blanks, etc.).  However, a simple thing like being able to make a 
copy of a mac application residing on the IBM from the IBM doesn't work.  
This is because Centram split up the data and resource forks into two 
separate DOS files, with the resource fork being hidden (making them 
contiguous would make more sense to me but there must have been some good 
reason not to do that).  So you can't copy any file that has a resource 
fork properly.  

On the DOS version, when you go to publish a volume, it runs a program 
called XSYNC.  I'm not exactly sure why they need to run it, but it seems 
to do a tree find from the directory you are publishing on down.  
Publishing a 20 Meg hard disk with lots of file took between 5 and 10 
minutes.  THIS IS REDICULOUS!  

We tried their simple example of creating a lotus spreadsheet and then 
reading it in with Excel.  The IBM crashed as soon as we tried to access 
the spreadsheet from the Mac.  (We subsequently got this to work, who knows 
why.) Great.  

When using the IBM as a client to a server Mac, you get full hierarchical 
access to HFS volumes.  When you try to do this in the opposite direction, 
you only get an MFS volume.  Why?  Who knows, it doesn't say why in the 
manual.  

Aside from all these problems, it generally doesn't do much!  It doesn't 
have an email application, it doesn't have a "chat" mode, and no spooler 
either.  Compared to some of the DOS compatible networks I've heard about, 
I'd say this is a serious lack of functionality.  

As you can tell, I'm not satisfied.  I don't see any reason why it can't be 
good -- it just needs more work.  If Centram keeps at it, it may evolve 
into something useful.  At this point, I'd be scared to share data with 
it.  
-- 
Robert Berlinger
Systems Analyst
Albert Einstein College of Medicine

UUCP:       ...{philabs,cucard,pegasus,ihnp4,rocky2}!aecom!naftoli
Compuserve: 73047,741

tim@hoptoad.uucp (Tim Maroney) (09/07/86)

This is a response to Robert Berlinger's review of TOPS.  Disclaimer: I am
an employee of Centram, not a disinterested observer.  When I *was* a
disinterested observer, however, I chose to accept employment at Centram
largely because I was impressed with TOPS....

>My real problem with it is that it isn't robust.  For instance, if the
>server or client crashes, TOPS doesn't seem to register that, and either
>thinks it is still talking or just hangs.

TOPS has gone through months of beta testing in addition to our extensive
testing in-house, and we feel that it is very robust.

A dialog that says that there are difficulties always comes up within ten to
twenty seconds after the connection is broken, if there is a pending client
file operation.  If there is no pending operation, then the connection may
be broken silently, which will cause any further client operations to return
an error status.  I am not sure what you mean by "thinks it is still
talking", but we have not observed the system hanging, nor had such behavior
reported to us either in beta test or since release.

>Also, some very common actions can bring down the server as far as the
>network is concerned.  Since TOPS runs as what Centram calles a "hidden
>DA", it will stop functioning if you go into the minifinder!  Although this
>is mentioned in the manual, I think this is a rediculous restriction.

That's why we got rid of it!  The manual does say that, and it was true in
the initial beta release.  In the released product, however, TOPS works fine
with the MiniFinder.  The release notes mention that this has been fixed.

>Copying files on the server brings clients to a grinding halt, and
>formatting any floppy (although you get a warning) will kill off any
>clients you have.

Disk initialization does not crash either the server or the client; it just
makes the clients wait until the server has finished formatting the disk.

Scheduling presents difficulties on the Mac because of the lack of
multitasking.  We have gone to great lengths to make TOPS run concurrently
with virtually all Mac software.  Unfortunately, some activities on the
Macintosh are very difficult to break into by any means.  Disk
initialization is time-critical; try breaking into MacsBug during disk
initialization, waiting a few seconds, and then returning: the
initialization will fail.

File copying in the Finder is less problematic, and we are working on allowing
TOPS to run concurrently with it; but it may never be possible to run
concurrently with disk initialization.

>Although the following problems aren't really Centrams fault, they are
>issues that have to be dealt with in terms of networks in general.
>
>1.  The Finder was never meant to be used with multiple users per disk.
>    Problems like trashing desktop files (happens often since there is only
>    one for all those simultaneous users!), files put in the trash showing
>    until empty trash is executed, etc.  make life difficult.

Desktop trashing happens very rarely, but it does happen.  Of course, it is
easy to recover from.

The Finder is being revised within Apple to better support file service
environments.  I agree, it is a problematic program, not only because of the
Desktop file, but because it patches OS traps in hideous ways.  It is also
rather buggy all by itself, as is usual with large assembly-language
programs.  Try running it with Heap Scramble sometime and watch the
fireworks!  (Do this on an unimportant floppy, though...)  However, its
problems with file service should be rectified in the near future.

>2.  Copy protected programs don't like to run over the network.  In fact,
>    at least one which I tried (Fontographer with its heavy protection, damn
>    them) crashed the client system altogether.
 
Of course!  In almost all cases it would violate the license agreements on
the software to run over the network in this fashion.  Should a developer
wish to allow such access, we are working on a licensable network copy
protection scheme.

>3.  Lots of programs don't like to run from write protected volumes because
>    they need to create temp files.  In addition, a lot of these programs
>    create temp files that don't have unique names, so they crash if two
>    people use them at once from the same folder.

This is a problem with the applications.  Apple has recommended that Mac
programmers use non-conflicting temporary file names, essentially through a
simulation of the UN*X mktemp libary routine.  However, this advice has been
largely ignored.  There's not a whole heck of a lot we can do about this.
If people don't start to get their act together, we may have to implement a
hideous ugly solution by intercepting file system calls on particular files.
Obviously, we would rather that developers take the extra few minutes to run
their applications correctly.  Note also that the Mac OS (specifically, the
Launch trap and the Finder) does not support the same file being launched
more than once, yet.

>Now on to the PC end.
>
>Although TOPS is supposed make the differences between OSs seem
>transparent, it doesn't do a very good job of it.  It does a pretty good
>job with handling the file naming issue (DOS is 8.3 with no blanks, Mac is
>31 with blanks, etc.).

Thanks!  That's the part I did.

>However, a simple thing like being able to make a
>copy of a mac application residing on the IBM from the IBM doesn't work.
>This is because Centram split up the data and resource forks into two
>separate DOS files, with the resource fork being hidden (making them
>contiguous would make more sense to me but there must have been some good
>reason not to do that).  So you can't copy any file that has a resource
>fork properly.

I think it's pretty obvious why they can't be in the same file.  This is not
file transfer, it's file service.  That means that a file is not a static
entity; it can grow or shrink, and either or both forks must be able to
change in size efficiently.  This can't happen if you lump them both together
into one file.

As for copying resource forks, we are writing a TOPSCOPY utility, but it
didn't make it out in time for the release.  Usually, you only need to do
this from the Mac in any case, and this works fine.

>On the DOS version, when you go to publish a volume, it runs a program
>called XSYNC.  I'm not exactly sure why they need to run it, but it seems
>to do a tree find from the directory you are publishing on down.
>Publishing a 20 Meg hard disk with lots of file took between 5 and 10
>minutes.  THIS IS REDICULOUS!

And unneccessary.  The naive user interface, TOPSMENU, does always invoke
XSYNC.  We expect that if you are publishing a whole hard disk, you will do
it fairly often, and so will set up a batch file that publishes it using the
TOPS commands.  The command language interface (which you would use in a
batch file) does not do the XSYNC unless you ask it to, and the XSYNC does
not need to be done every time.

>We tried their simple example of creating a lotus spreadsheet and then
>reading it in with Excel.  The IBM crashed as soon as we tried to access
>the spreadsheet from the Mac.  (We subsequently got this to work, who knows
>why.) Great.

We do this all the time, and this has never happened.  It only happened once
to you.  I see no reason to assume TOPS is at fault.

>When using the IBM as a client to a server Mac, you get full hierarchical
>access to HFS volumes.  When you try to do this in the opposite direction,
>you only get an MFS volume.  Why?  Who knows, it doesn't say why in the
>manual.

In HFS, Apple inflicted on the world a monster called "directory ids".  Not
only does each directory have a name, it has a permanent number.  This is
not really a bad idea in itself, but it creates problems when interfacing to
other operating systems.  The problem is not insurmountable, and eventually
there will be two-way HFS communication between the Mac and MS/DOS; but it
is tricky, and as a result this didn't make it into the initial release.

Note that there is a similar problem on the UN*X server.  Inodes correspond to
directory IDs, but without kernel hacks there is no way to access the inode
numbers when you need to.  Again, this is all because of the need to support
Apple's HFS completely.

>Aside from all these problems, it generally doesn't do much!  It doesn't
>have an email application, it doesn't have a "chat" mode, and no spooler
>either.  Compared to some of the DOS compatible networks I've heard about,
>I'd say this is a serious lack of functionality.

TOPS is a file service product, and has always been represented as such.
Now that most of the work on TOPS is done, we are moving on to other network
products, including the three you mentioned, remote terminal service to
Internet hosts, and other keen things.

>As you can tell, I'm not satisfied.  I don't see any reason why it can't be
>good -- it just needs more work.  If Centram keeps at it, it may evolve
>into something useful.  At this point, I'd be scared to share data with it.

I don't know what your application is, but your fears are unfounded.  To
cite just one example, as mentioned in MacWorld magazine, Martin Marietta is
using TOPS in their space station design project.  We have hundreds of
satisfied customers and many rave reviews.

Many of your problems were caused by cursory reading of the documentation
and could have been resolved by a single call to our support personnel.
Other problems, such as the MiniFinder "problem" which does not exist in the
released product, were apparently brought up not because you actually
encountered them, but for unknown reasons of your own.

TOPS is not perfect; no software is.  But it is transparent, simple, robust,
and extremely useful for file sharing applications.
-- 
Tim Maroney, Electronic Village Idiot and Certified Catholic Theologian
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)

Die daily.

naftoli@aecom.UUCP (Robert N. Berlinger) (09/09/86)

Re: Tim Maroney's response to my TOPS complaint list.

First of all, thank you for responding -- it's unusual to get an 
informed response on this kind of thing.  

I have some questions and comments --

> >For instance, if the
> >server or client crashes, TOPS doesn't seem to register that, and either
> >thinks it is still talking or just hangs.

> A dialog that says that there are difficulties always comes up within ten to
> twenty seconds after the connection is broken, if there is a pending client
> file operation.  If there is no pending operation, then the connection may
> be broken silently, which will cause any further client operations to return
> an error status.  I am not sure what you mean by "thinks it is still
> talking", but we have not observed the system hanging, nor had such behavior
> reported to us either in beta test or since release.

This problem was reported to me, and I couldn't get it to happen
when I tested it myself.

> >Also, some very common actions can bring down the server as far as the
> >network is concerned.  Since TOPS runs as what Centram calles a "hidden
> >DA", it will stop functioning if you go into the minifinder!  Although this
> >is mentioned in the manual, I think this is a rediculous restriction.
>
> That's why we got rid of it!  The manual does say that, and it was true in
> the initial beta release.  In the released product, however, TOPS works fine
> with the MiniFinder.  The release notes mention that this has been fixed.

My fault.  Although I did read the release notes, I didn't see this.  It's
not as well advertised as the note in the manual that says that it won't run.
It also reinforces my dislike of release notes.  

> >Copying files on the server brings clients to a grinding halt, and
> >formatting any floppy (although you get a warning) will kill off any
> >clients you have.
> 
> Disk initialization does not crash either the server or the client; it just
> makes the clients wait until the server has finished formatting the disk.
> Scheduling presents difficulties on the Mac because of the lack of
> multitasking.  We have gone to great lengths to make TOPS run concurrently
> with virtually all Mac software.

I think the alert may have confused us into believing they got 
killed off.  It said something like, "if you continue, clients 
may lose work" meaning that they would be killed off.  Maybe this 
message should be changed to "clients will have to tread water 
until the init is over" :-).  Also, I didn't always get the 
message.  

I didn't mean to make it sound like it was TOPS' fault that the 
disk initialization halted or killed the network, in fact, it's 
pretty nifty that they were able to patch in the alert.  But I 
did want to let potential customers or users know about the 
inconvenience.  

> >2.  Copy protected programs don't like to run over the network.  In fact,
> >    at least one which I tried (Fontographer with its heavy protection, damn
> >    them) crashed the client system altogether.
>  
> Of course!  In almost all cases it would violate the license agreements on
> the software to run over the network in this fashion.  Should a developer
> wish to allow such access, we are working on a licensable network copy
> protection scheme.

No one can tell me that it's normal for any program to crash my 
system under any circumstances, no matter what the situation.  A 
mere "NO DICE" alert would suffice.  As I indicated, this flame 
is not directed at CENTRAM or TOPS.  

> >Publishing a 20 Meg hard disk with lots of file took between 5 and 10
> >minutes.  THIS IS REDICULOUS!
> 
> And unneccessary.  The naive user interface, TOPSMENU, does always invoke
> XSYNC.  We expect that if you are publishing a whole hard disk, you will do
> it fairly often, and so will set up a batch file that publishes it using the
> TOPS commands.  The command language interface (which you would use in a
> batch file) does not do the XSYNC unless you ask it to, and the XSYNC does
> not need to be done every time.

I knew that it was possible to publish without the XSYNC.  The 
problem was that it wasn't clear to me from the manual when you 
do or don't need to run XSYNC.  Does it need to be done every 
time the filesystem on the PC gets changed?  If so, what is the 
reason for implementing it in this (less automatic) way?  

> >We tried their simple example of creating a lotus spreadsheet and then
> >reading it in with Excel.  The IBM crashed as soon as we tried to access
> >the spreadsheet from the Mac.  (We subsequently got this to work, who knows
> >why.) Great.
> 
> We do this all the time, and this has never happened.  It only happened once
> to you.  I see no reason to assume TOPS is at fault.

Simply because it never happened until we ran TOPS.  It may have 
been caused by some conflict with other memory resident 
utilities, mouse driver, I don't know (thank you Apple for the 
sanity of DA's!!!).  

> >Aside from all these problems, it generally doesn't do much!  It doesn't
> >have an email application, it doesn't have a "chat" mode, and no spooler
> >either.  Compared to some of the DOS compatible networks I've heard about,
> >I'd say this is a serious lack of functionality.
> 
> TOPS is a file service product, and has always been represented as such.
> Now that most of the work on TOPS is done, we are moving on to other network
> products, including the three you mentioned, remote terminal service to
> Internet hosts, and other keen things.

I didn't mean to make it sound like TOPS was misrepresented in 
the advertising.  On the contrary, I knew exactly what I was 
getting.  I was simply making a general comparison of its level 
of functionality to some of the existing networks that I've 
seen.  Good to hear that new things are on the drawing table.  

As a final word, several of the problems that I mentioned will be 
fixed with new utilities, functionality, etc., in the "next 
release." It may be that I expected too much too soon, but I've 
been waiting for a good network product for so long, and I'm beginning to 
get impatient.  

TOPS is well priced, and may yet turn out to be a Classic Mac 
product (the finest kind).  

Thanks for the comments and explanations, Tim.
-- 
Robert Berlinger
Systems Analyst
Albert Einstein College of Medicine

UUCP:       ...{philabs,cucard,pegasus,ihnp4,rocky2}!aecom!naftoli
Compuserve: 73047,741