INFO-MAC@SUMEX-AIM.STANFORD.EDU.UUCP (02/05/87)
INFO-MAC Digest Wednesday, 4 Feb 1987 Volume 5 : Issue 48
Today's Topics:
str255 help
Font/DA Mover help
Re: Another stupid posting about INITs
Re: Apple NuBus to VMEbus adapter
400K DD seek scraping, ejecting
ImageWriter II Print Problems
TransSkel - Request for comment
SFGetFile/SFPutFile ideas
Re: Another Mac Interface Comment
Troff to Mactintosh converter request
About my Randomizer INIT
UTILITY-PAGE2SAVER.HQX
Re unprotecting MS-BASIC files:
AppleShare--turn your Mac into a fileserver
new book "Under the Apple"
Porting TeX-Fonts to Mac/TeXtures
color laserwriter cartridges
Church software for the Mac
MacModula-2 V4.0
Centram Systems has been bought out by guess who
----------------------------------------------------------------------
Date: Tue, 3 Feb 87 15:00 EST
From: JPB%SMVL%rca.com@RELAY.CS.NET
Subject: str255 help
I am using TML Pascal to write a file translator program. I like
TML Pascal a lot, its Pascal in general I'm having a great deal of
trouble with. Actually just str255. I am trying to read files with
the following format:
xxyy<variable length data>
where xx is an integer specifying record length in bytes(including
xxyy) and yy is an integer signifying record type. Everthing works
file until I try to put a string record into a str255 variable. The
first character gets chopped off and used as a length byte. I have
keep an accurate representation of what the string is because I need
to reference data that follows the string name. I have tried variant
records, packed arrays, and a whole bunch of other stuff that other
programmers around here have suggested. I either get compiler errors
or garbage in my str255 variable. Does anyone have an idea as to some
hidden ROM or system routine to stick a count in front of a set of
ASCII characters so that I can make this silly program work and go back
to interesting things like playing with World Builder!!! Has anyone else
ever lost sleep over this besides me??
THANX for any and all help in advance!
------------------------------
Date: 2 Feb 87 16:11 EST
From: HALLETT%CSBVAX.decnet@ge-crd.arpa
Subject: Font/DA Mover help
What is the key sequence that allows one to install Desk Accessories into
applications via the Font/DA Mover? Will a similar sequence work for Fonts?
JAH
------------------------------
Date: Fri, 30 Jan 87 14:48:47 pst
From: decvax!decwrl!voder!apple!lsr@ucbvax.Berkeley.EDU (Larry
From: Rosenstein)
Subject: Re: Another stupid posting about INITs
In article <8701300810.AA26082@ucbvax.Berkeley.EDU> you write:
>Date: Thu, 29 Jan 87 17:10:35 PST
>From: PUGH%CCC.MFENET@nmfecc.arpa
>Subject: Another stupid posting about INITs
>
>Now I am trying
>to write to the screen during an INIT. It ain't easy. A5 is screwed and so
>are all the initialization routines. That means I can't use the window
>manager to create a grafport to draw in. Everything just hangs.
>
I wrote a little screen dimmer that writes on the screen when it installs
itself. I just called InitGraf, InitFonts, OpenPort, and DrawString, and
it works fine. A5, A6, and A7 should be all setup.
>Date: Thu, 29 Jan 87 09:50:46 PST
>From: PUGH%CCC.MFENET@nmfecc.arpa
>Subject: One last thing on LSP INITs
>
>There is a check box in ResEdit's INIT GetInfo box that tells the system to
>lock the code while running.
Actually any resource can have its lock bit on, and then the Resource
Manager will automatically lock the resource when it is read in. This does
not mean that it will always stay locked, but this will work with INITs.
>If you have several INITs in a file, they are NOT run in numeric order. The
>numbers seem to be pretty useless. Instead, they are run in the reverse order
>that ResEdit lists them.
The system uses GetIndResource to sequence through them. You should not
depend on the order in which GetIndResource returns resources. If one INIT
needs to run before another, you should make the second one a different type
of resource and have the first explicitly load it in and run it.
>Date: 29 Jan 87 11:21 EST
>From: HALLETT JEFFREY A <HALLETT@ge-crd.arpa>
>Subject: Disk Icons ala Feb. MacUser article
Drawing icons is convered in Technical Note #55. It says the same thing;
the mask is used (with bit clear mode) to punch out a white hole and the
data is XORed. For a selected icon, the mask is ORed to make a black hole
and the data is XORed again. The other cases of off-line and open icons are
also described.
Larry Rosenstein
Object Specialist
Apple Computer
AppleLink: Rosenstein1
UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET
------------------------------
From: BGT.WB%GEN.BITNET@cernvax
Date: 02 feb 87 22:18 GMT +0100
Subject: Re: Apple NuBus to VMEbus adapter
CERN is developing such an interface. It is compatible with the
current implementation of MacVEE (Microcomputer Applied to the
Control of VME Electronic Equipment) on the Macintosh Plus (see
INFO-MAC Issue 5/14).
I can't send out information until Apple officially announces
the new computer, but if any professional researchers would like
to be at the top of the list to receive details when that time
comes, they are welcome to send me their coordinates. Mention
in your request whether you are currently a MacVEE user or
require a manual for that system too.
B.G. Taylor
EP Division
CERN (European Organization for Nuclear Research)
CH-1211 Geneva 23
Switzerland
Bitnet: bgt.wb@gen
Arpanet: bgt.wb%gen.bitnet@wiscvm.arpa
Usenet: bgt.wb@gen.bitnet.uucp
------------------------------
Date: Wed, 04 Feb 87 17:34 CST
From: Richard <Tilley@UOFMCC>
Subject: 400K DD seek scraping, ejecting
Have '84 stock fat mac. Ran 1 yr as single drive system so
drive (and thumb) got lots of use. A year ago drive made
fearful *scraping* noises while seeking. No grinding here.
Noise was intermittent - perhaps 50%. Sounded like all the
oxide was being scraped off the disk. However no I/o errors
and only the occasional tiny scratches that have been mentioned
here in the past.
Cleaned the pad and head and splashed oil on most everything
that moved, especially that long spiral gear. No change.
The noises eventally went away and havent returned. I suspect the
stepper. Heard another machine make the same noise just once.
More recently had problems with disks failing to eject. Also
intermittent but got worse and worse. Putting a tiny washer
between the eject motor and the frame fixed it.
------------------------------
Date: Sun 1 Feb 87 10:54:15-MST
From: Robert J. Thum <RTHUM@SIMTEL20.ARPA>
Subject: ImageWriter II Print Problems
Seems like my request for info from others with printer problems of
"SQUISHED" top lines has opened the flood gates! The general feeling is
'There is a problem', the way people are trying to solve the problem are
indeed varied. The basic problem is quite simple: The ImageWriter II
randomly squished the first line of text or graphics when in ony print mode
other than draft, and even in that mode on very very rare occasions.
Richard.Etner@PSI states that he notices that if you follow the Image-
Writer II manual for paper placement the top edge will buckle a bit as it
struggles to get under the rollers. He now positions the pagper so that the
bar supporting the rollers is midway between the first two pin feed holes.
"(This requires a concomitant bottom margin software adjustment)". Joe
Touch@SVAX notices the fold of fanfold paper often doesn't ride under the
little roller bar smoothly. When it gets stuck (near the top of every other
page) and doesn't advance the print overlap and apperars 1/2 high. He
states there are two basic "fixes":
1. Don't use fanfold paper or unfold it before printing.
2. Load the paper so that the 'fold-bump' is already under the
roller bar when the top line of the paper prints.
Joe also quoted from ABRAHAM MASLOW " When the only tool you have is a
hammer, everthing begins to look like a nail". Hank from Well!@III thought
the problem may be the system board in the ImageWriter II but after
replacing the thing it did not improve the problem. Hank also noted that a
lady in Canada had all the gears and platen replaced which cured hre
problem. I have noticed (after having it pointed out to me) the same
tendencies in that every other page-IE: the one with the 'fold-bump' up
gets squashed letters. Michael Knight@Maine wrote that the slop in the
tractor feed seems to be the problem caused by the advancing and then
retracting of the paper.According to Macintosh Technical Note #33 it seems
that A. The pager should be positioned with the top edge at the pinch
roller, making it easy to rip off the printed page(s). Also at the end of
the TN it is noted that "there is also the "burp" This is a 1/8 inch motion
back and forth to take up the slop in the printer's gear train. It is
needed on the old-model printer, and there is debate about whether or not
it's needed on ALL ImageWriter II's or only some, or none. The burp has
been in and out of the ImageWriter II code in various releases; right now
it's in. This TN was written by Ginger Jernigan April 30,1986.
>FLAME ON: Since this seems to be a wide spread problem where is the Apple
support? On Apple link the local dealer could find nothing concerning this
problem and no technical bulletin has been received by the service dept.
according to their service tech. Come on Apple, fist the power supply in
the Mac and now the ImageWriter II we understand your preoccupation with
the LaserWriter but there are bunches of ImageWriter II and I still out
here and we need help also. (we still use the famous system 3.0 and 3.1)
>FLAME OFF: I will continue to keep you posted on this continuing saga as
new reports are received.
RTHUM@SIMTEL20
------------------------------
Date: Fri, 30 Jan 87 16:06:19 CST
From: Paul DuBois <dubois@unix.macc.wisc.edu>
Subject: TransSkel - Request for comment
After posting the recent fixes to the TransSkel stuff, I received
some comments that I think warrant more general discussion. Briefly,
my correspondent believes that TransSkel's behavior with respect to
setting ports is wrong, but I will let him speak for himself:
> From the initial release of TransSkel I've felt that it handles one
> thing incorrectly: the setting of the current port. There are two
> places only where TransSkel should change the current port: in response
> to an activate event and in response to an update event. In the latter
> case the port should be changed temporarily to the window to be
> updated, the update procedure for the window should be called, and then
> the port should be restored. ** From the user's viewpoint the port
> doesn't really change.** In the case of activate events the port is
> permanently changed to the window being activated, presumably in
> response to some user action. ** From the user's viewpoint the port
> only changes in response to some action of his.** This is in the
> spirit of the user interface guidelines, and you won't find anything in
> Inside Macintosh to indicate that things should be done otherwise.
> In no other situation does TransSkel have any business messing with the
> port, but in fact it changes the port all over the place. This strikes
> me as just asking for bugs to crop up.
> In general the application program built on top of TransSkel should not
> change the current port, and when it does it should be a temporary
> change in the space of a single procedure, much like the change during
> update. ** Application programmers need to understand this, not have it
> magically enforced by excessive use of SetPort within TransSkel.**
> The proper way to remove a window is to hide it, to handle the deactivate/
> activate events locally, and to then dispose of the hidden window.
> This would eliminate the problem you had with ZoomWindow without yet
> another unnecessary SetPort.
My response to this was partial agreement. I did ask what the
port should be set to when a window gets clobbered. TransSkel sets
it to the window manager port to avoid dangling ports. Perhaps
this is unnecessary; the response to my question was:
> What do you set the port to when a window is disposed? Is it
> necessary to set it to anything? Activate events should cause the port
> to be set. When the last window goes away there won't be an activate
> event, but neither will there be any further update events; so the
> user's program shouldn't be doing any more drawing that requires the port
> to be set.
> One addition to my suggestion in the previous mail: the routine that
> handles the deactivate/activate events locally when you hide a window
> in preparation for disposing of it might ought to handle outstanding
> update events also.
> By the way, this idea is not original with me. I've encountered it in
> other people's code ... Stephen Chernicoff explains
> this technique for closing windows on pages 86-87 of Macintosh
> Revealed, Volume Two.
Anyone have any comment? I think the remarks above has merit, but
I'd like to hear what other people thing before I start hacking away.
Paul DuBois UUCP: {allegra,ihnp4,seismo}!uwvax!uwmacc!dubois
ARPA: dubois@easter
dubois@rhesus 3-Feb-87 07:14:19-PST,1542;000000000001
------------------------------
Date: 3 Feb 1987 09:51-EST
From: Bruce.Horn@vlsi.cs.cmu.edu
Subject: SFGetFile/SFPutFile ideas
I agree with adding the interesting key-equivalents to SFGet/Putfile
(cancel, cut/paste, etc.) as well as keys to:
1. Get to the top of the hierarchy;
2. Go up one level.
I can always type to get a file I want anywhere, as long as I start at
the root. A key to get there would be very convenient.
Henry Lieberman's idea to have a true root, and select the drive just
as folders and files are selected is a good one. Does somebody want to
rewrite the package with all our wishes and distribute it?
On SFGetFile viewed as the Finder: we tried very hard to do this in
the early days of the Mac. (Of course, what we REALLY wanted was for
the Finder to always be around, like Servant.) Steve Capps wrote
several versions of the "Minifinder" as we called it in those days,
using some Finder code, and it turned out that with the machine we had
and the lack of memory, it was just TOO SLOW. (When thinking about the
Finder, remember the original target machine and the limitations we
faced...) Steve then wrote SFGet/PutFile instead, which had reasonable
performance. It wasn't the "small machine mentality," as Henry said,
but the "small machine reality."
Bruce
------------------------------
From: "Steve Munson" <sbm@purdue.edu>
Subject: Re: Another Mac Interface Comment
Date: Wed, 04 Feb 87 09:05:25 EST
If only to add weight to the complaint, I would like to make it
known that I agree with Kathleen Huddleston that two of the Mac's
serious problems are lack of multitasking and the mysterious way in
which fonts and DAs are added to the system.
The need for multitasking can clearly be seen from the
proliferation of DAs floating around. It is impossible to install all
the useful DAs in a single system file, and, if the "ideal" system were
put together (word processor, background printer, compiler, etc., all as
DAs), it would completely eliminate the use of icons. I think that,
probably in some new Mac architecture, DAs should be done away with as
soon as possible, and multitasking should take their place. Of course,
current Mac owners would never tolerate the elimination of DAs now.
I think we can all agree that the treatment of fonts and DAs is
completely contrary to the Macintosh interface. In any computer system,
but especially in the Macintosh system, it should be simple to do simple
things. Moving fonts and DAs is conceptually simple, if
implementationally messy. The paradigm is already there for moving
files; you simply move icons. There is no excuse for having a different
paradigm for moving fonts and DAs. All that can do is confuse and
frighten the inexperienced user, and the Macintosh is not supposed to be
a frightening computer. The current interface could be improved by
allowing fonts and DAs to be files separate from the system file (the
preferable way), or it could simply provide a more intuitive way of
installing and removing them. I have heard that Andy Hertzfeld is
taking a step in the right direction with Servant, which has some
features of ResEdit built into it.
All in all, the Macintosh operating system provides little
improvement over CP/M (think about it--what's the difference?), and
should have been written completely differently in the first place. Now
that it has become so entrenched, it cannot be replaced by a real
operating system without obsoleting all the Macintosh applications ever
written. It is clearly possible for processes to do the same things
with windows, etc. that applications do, but the assumption applications
make that they can take over the machine makes it impossible for them to
fit into the kernel/process model. Such are the woes of an operating
system that was obsolete when it was released.
Steve Munson
sbm@Purdue.EDU
sbm@Purdue.CSNET
------------------------------
Date: Mon, 2 Feb 87 19:35:43 MET
From: Francie Newbery <newbery%germany.csnet@RELAY.CS.NET>
Subject: Troff to Mactintosh converter request
I would be interested in finding out what programs are available for
conversion between files containing standard text formatter source (i.e.
Troff, TeX) and Macintosh files.
In particular, we have a large number of troff files which we would like to
maintain on the Mac from now on. We would prefer, if possible, to not have
to redo all of the formatting. Copying a file (with or without formatting
directives) to the Mac is not a problem. Is there perhaps a program that
can do at least some of the reformatting for me?
A program that would convert Macintosh to simple TeX would be of
interest too, but that's probably asking too much.
Please respond via mail as we do not currently receive info-mac
at our site.
Thanks in advance,
Francie Newbery (newbery@germany.csnet, unido!uka!newbery, fjn@cs.purdue.edu)
------------------------------
Date: Mon, 2 Feb 87 08:24:25 PST
From: PUGH%CCC.MFENET@nmfecc.arpa
Subject: About my Randomizer INIT
One thing I forgot to mention in my posting is that Randomizer INIT can deal
with logical groups of Screens and Sounds. That means you can have a screen
that always uses a certain sound, and a Sound that can only be used with a
certain screen. It's all explained in the document included with the INIT.
Check it out.
Jon
------------------------------
Date: 31 Jan 87 15:46:41 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: UTILITY-PAGE2SAVER.HQX
[ Uploaded from Delphi by Jeff Shulman ]
Name: PAGE2SAVER
Date: 27-JAN-1987 02:59 by LOGICHACK
A small utility to reserve the second video/sound pages at startup so that
games like Megaroids will work without having to turn off the Apple disk
cache. Simply put it in your System Folder and reboot to have it take
effect. This does use up over 20K of your memory.
[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>UTILITY-PAGE2SAVER.HQX
DoD
]
------------------------------
Date: Mon, 2 Feb 87 18:12:40 PST
From: Alex_Curylo%SFU.Mailnet%UBC.MAILNET@MIT-MULTICS.ARPA
Subject: Re unprotecting MS-BASIC files:
I seem to recall that 'protection' is a simple 1-bit flag near the
beginning of the file, and flipping that bit is all you need to do.
My approach would be:
1. Write a short program in BASIC
2. a) Save it unprotected b) Save it protected
3. Boot up Fedit+ or equivalent and compare the two files. They should
differ by only a single byte.
4. Flip the byte in the same position in the file which was inadvertently
protected (NB a COPY of that file).
If that doesn't work, I'd convert the file type to TEXT. The program should
still be there in token form ("?" for PRINT, etc.) which will fix itself back
to BASIC code automatically, with a little cleaning up around the beginning
needed.
Good luck.
------------------------------
Date: Mon, 2 Feb 87 22:24:49 pst
From: gould9!joel@nosc.ARPA (Joel West @ Western Software Technology)
Subject: AppleShare--turn your Mac into a fileserver
I saw a demo of AppleShare today. It was very impressive. The Mac developer
who's been using it in house for about a week claims it will put Apple a big
leg up on IBM. His comment was that it was the best multi-user software
available for a micro, and what I saw backed that up. Certainly, short
of multi-tasking, it looks good enough to support a 'desktop engineering'
machine if Apple ever stops planting rumors and finishes the hardware. :-)
Take an extra Mac Plus (or a 512 (e?) with a 3rd-party SCSI port), add a
decent size SCSI drive and a few feet of AppleTalk cable. Now, give
$799 to Apple for 'AppleShare', a software package. Once you pay for
the server, you get an 'RDEV' (special driver) file called AppleShare to
put in each Mac's system folder.
The nice thing about using software is that there's no critical-path
bottleneck on shipping a particular device, and all Apple's third-party
hardware people are happy. Buy any hard disk you want, 20 to 200 mb,
and you're in business.
Each user can 'log in' to anyone of the servers (there can be more
than one) automatically on boot. Each human has a username and a
password; humans can ask that their password be encrypted on their
personal hard disk and thus their machine connected to the server
upon boot. As I recall (I don't have the server in front of me)
this is controlled by the 'Access Privileges' DA. The speed seemed
faster than a floppy, slower than a direct SCSI drive. Wait, there's more...
So you look at your desktop, and there's another disk, with a bunch
of folders. Some are shared; a few are yours, which you can set
User, Group or World access to. But wait, there's more....
Does anyone remember the 'write-only memory' spec sheet of a few years back?
Well, AppleShare includes a write-only folder. Everybody can have their
own private in-box folders. You can put things into someone's folder,
but you can't see what's there.
At Macworld, John Sculley talked about how everyone felt that desktop
communications meant transfering data around. But really where it's at
(to paraphrase) is document sharing. This is the other shoe - Apple's
strategy for communications is this transparent fileserver. Why mess
around with electronic mail when you can just dump your MacWrite or
Excel or MPW document in someone's inbox, and he can read it from within
his application at any time.
The server software has some status windows to show who's logged on.
When it's time to shutdown, the server operator sets a delay and every
five minutes until shutdown, an Alert() pops up on the user's screen
noting the imminent shutdown.
Supposedly AppleTalk PC cards have been unveiled, which allow IBM
PC's to print documents on the LaserWriter and draw files from
the fileserver. Available now, $399. A free program to read
IBM DCA files and produce MacWrite files is doo 2nd quarter,
as are a 3270 document converter and a laser print spooler.
AppleShare comes with Finder 5.4/System 3.3. Get Info is smaller and quicker,
Get Privileges (only with the fileserver) is the same size, the Access
Privileges DA is new. Print Catalog has a PrJobDialog now. Yes, the
trash can bulges when it has something.
Chooser selects fileservers and printers. The AppleTalk button is back,
and it now handles intelligently switching between a printer and AppleTalk
on the printer port.
Finally, as noted (in Delphi?), there are three cleanup operations in the
finder - cleanup, cleanup window, cleanup selection. Not only does
cleanup window change to cleanup selection in the menu (when you have
a selection), but when you hold down option, it changes to cleanup.
If you're going to use a trick like that, that's the way to show it.
Joel West ihnp4!gould9!joel
Western Software Technology joel%gould9.uucp@NOSC.ARPA
------------------------------
Date: Tue, 3 Feb 87 18:26:53 PST
From: <DAVEG@slacvm.bitnet>
Reply-to: DAVEG%SLACVM.BITNET@forsythe.stanford.edu
Subject: new book "Under the Apple"
I got a copy of a new Macintosh book called "Under the Apple" about
Macintosh desk accessories. It is written by Howard Bornstein, author of
a monthly column for the Macazine called POWER WINDOWS. The book contains
a very nice review of many DAs for the Mac, and is a must book for those
who have done little exploration of desk accessories beyond those for
Apple. Those who have more experience may still find this book useful since
it contains nice summaries of DAs by functionality and it reviews some of the
major collection disks like TopDesk, Batteries Inc., etc.
David Gelphman BITNET address: DAVEG@SLACVM
Bin #88 SLAC ARPANET address: DAVEG@SLACVM.BITNET
Stanford, Calif. 94305 UUCP address: ...psuvax1!daveg%slacvm.bitnet
415-854-3300 x2538
------------------------------
Date: Tue, 3 Feb 87 10:40:29 -0100
From: unido!gmdzi!yvw@seismo.CSS.GOV (Yvo Van Wezemael)
Subject: Porting TeX-Fonts to Mac/TeXtures
After we finally got a release of TeXtures (0.95c), there is one
problem left:
Due to the fact that we are already using TeX on our Mainframes,
Vaxes, Suns etc. for a long time, we have some Fonts of our own.
(Built with Metafont.)
So the question is:
Is there an easy way to use these Fonts on a Mac, i.e. convert them
to Mac-Fonts. (Easy includes buying a program if no free-/
shareware-tools exist.)
Thanks for your help
Yvo
------------------------------
Date: Mon, 2 Feb 87 16:32:47 est
From: jonathan@mitre-gateway.arpa (Jonathan Leblang)
Subject: color laserwriter cartridges
Does anyone know of anyone who either makes color laserwriter cartridges or
who will refill cartridges with color toner? Any help would be appreciated.
Thanks
Jonathan
ARPA: jonathan@bert.mitre.org
BITNET: leblangj@vtvax3.bitnet
MABELL: (703) 883-5761
USNAIL: 7525 Colshire Drive
McLean, VA 22102
Jonathan A. Leblang
The MITRE Corporation
------------------------------
Date: Mon, 2 Feb 87 12:17:52 CST
From: davis%mycroft@gswd-vms.ARPA (Tim Davis)
Subject: Church software for the Mac
I'm writing to find out if anyone out there is aware of good software
written for the Mac to perform Church related functions. These
packages could consist of Accounting Software, Spreadsheets, List managers,
DBMS but the most important thing is they must be integrated. There are
many these packages which are for the Mac and of excellent quality. The prime
reason for considering the Mac is the user interface. If it is not easy
to learn then it is of no use. There are many of these integrated
packages which exist for PC's but I would like to avoid the problems
associated with repeatedly teaching secretaries, treasures, and pastors
how to use the system. There is a fairly high turnover rate for the
first two groups.
Thanks for any assistance you can offer.
Tim Davis
1101 E. University
Urbana, IL. 61801
(217)384-8500
davis@gswd-vms.arpa
------------------------------
Date: 3 Feb 87 13:26:34 EST
From: Duane.Williams@f.gp.cs.cmu.edu
Subject: MacModula-2 V4.0
Can anyone tell me whether MacModula-2 V4.0 is Mac Plus compatible?
Mail responses are welcome. Thanks.
-Duane (dtw@k.cs.cmu.edu)
------------------------------
Date: Wed, 4 Feb 87 16:29:41 PST
From: <DAVEG@slacvm.bitnet>
Reply-to: DAVEG%SLACVM.BITNET@forsythe.stanford.edu
Subject: Centram Systems has been bought out by guess who
The San Francisco Chronicle had an article this morning (2/4/87) indicating
that Centram Systems (the TOPS people) have been bought out by SUN
Microsystems. This is a TOTAL surprise since there have been many articles
(including one in InfoWorld) indicating that 3COM was buying out Centram
Systems. I'm not sure that the deal is final, but the Chronicle indicated
that the offer from SUN was approximately 33% larger than the offer by
3Com. I sure wonder what all this means to those of us who are TOPS customers.
David Gelphman BITNET address: DAVEG@SLACVM
Bin #88 SLAC ARPANET address: DAVEG@SLACVM.BITNET
Stanford, Calif. 94305 UUCP address: ...psuvax1!daveg%slacvm.bitnet
415-854-3300 x2538
------------------------------
End of INFO-MAC Digest
**********************