--
Gilles SIMON
gil...@wanadoo.fr
Why should SCO go home? Are you positively sure that this is a SCO
problem?
Very well could be, but from the information above it looks like
Word2000 is where the problems began. Have you tried this from any
other peer-to-peer configurations (like a Windoze-to-Windoze, or 2000
<-> NT)?
At one customer site, I found Lotus 5 broke. . . . not SCO's problem,
and I found a patch from Lotus/IBM which fixed the problem.
Have you sent a bug report to SCO?
> und NT is comming in (but not from us :>(( ).
> Cheers Peter
>
Sent via Deja.com http://www.deja.com/
Before you buy.
OK, you are right but also nice,
the customer isn't interesting in such problems, taking a NT on
the other end and it works. I also think it's a thing with Word2000,
but what helps? All editors and viewers i tried work in a acceptable
time-range, BUT Word2000 would'nt - what will HELP???
Searching the TA's didn't give a match. Bug report to SCO, when do you
meen i will get an answer? So 'go home'.
Und as i reported the unixware host shows over 90% user-load over all
the waiting time, that can only be the visionfs, so it must be a
visionfs - SCO - problem. Nettraffic is only at the beginning.
Perhaps the problem is translation? I created the file obove with vi
and then stored it via unix2dos as test.txt, then "open with"
word2000.
Cheers Peter
The obviouis quick test to to create the doc with word2000 and save on
the server and then retrieve. I would be interested in the time to save
and the time to open the document.
Did you ever test opening the document with word2000 when it is on a
win98/winNT server ?
--
-bill-
Technical Service Systems - bi...@TechServSys.com
To A1: this test are opens the file directly, not asking for
Fileconversion. If word2000 ist asking for Fileconversion, then select
"text only" it takes 75 seconds.
NOW, I'm speakless :>>((( Don't now what's going on.
Thanks a lot for your response - any idea?
Cheers Peter
YES, i did. We connected the same WIn98 box to a NT4.0 server, copied
the test.txt-file from win98 box to NT-box (first got it from UW box
to win98-box) und timing was like as locally opening on win98 plus 5
seconds.
But don't have the possibility to check it on samba! Is there anyone
out who has results in that?
But a little better news i have now:
We installed the new ptf 4001o yesterday, timing is a little better
(ca. 2 sec.) and the long one goes down to 60 seconds >:0[].
But this is bad too.
I monitored via ps the 'vfsd --profile /scsi14/vision/vfsprofile' with
was fork to do the job and it shows a time of 1:22 for selecting the
icon 'test.txt'. start word2000 and open test.txt.(which was initiated
with the klick).
Now i will give up!
Is there, out in the wo(r)ld, nobody using word2000 on a UW213 box???
Nice days over Easter.
Cheers Peter
Hi Peter,
I too would recommend Samba, but allot of good people at SCO like Vision.
As far as removing *nix and replacing it with NT, well, it defies logic.
Samba is almost twice as fast than NT in file serving when I tested it
apples to apples to NT.
*nix machines up times are into the 300 day range, without 1 gig of RAM. NT
does not even come close.
You do not have to continuously purchase programs to get the machine to do
its job, like..
PC Anywhere, Termserver, ArcServe.....
I am looking for a good Exchange substitute, another M$ user addiction
program.
Just my 2 cents..
Christopher Cox
On Tue, 25 Apr 2000 11:29:08 GMT, "Christopher Cox" <co...@urec.net>
wrote:
> >I am looking for a good Exchange substitute, another M$ user
addiction
> >program.
> >
> >Just my 2 cents..
> >
> >Christopher Cox
Ever consider using the 'sendmail' which comes with UNIX? email
readers can POP messages off with their favorite reader, whether
OutLook, Netscape, Eudora, etc. 'imap' can also be used if you want to
keep messages on the server.
It also doesn't cost anything. . . .
MoJo Risin
> Hi Christopher,
> i think i should test the samba server but now, testing and asking for
> versionfs, my time goes to end.
> Do you know a bin of samba for UW213? for a quick test and demo?
> Thanks a lot
Try SCO's website.
BTW, why haven't you upgraded to UW 7.1?
I have now reproduced your problem with Word 2000 and engineering has
isolated the cause of the delay in opening the .txt files. I had been
opening the file from within Word, rather than opening the file
directly
with an association linked to Word, which is why I didn't see the
problem
before.
Engineering has taken a look at this problem and found the following
behaviour occurring:
Looking at a network trace of the open, what Word 2000 appears to be
doing
is looking for a number of converter files. The actual sequence of
calls
goes something like:
win: give me info on \dir
vfs: info about \dir
win: give me info on \dir
vfs: info about \dir
win: give me info about \dir\somefile.doc
vfs: \dir\somefile.doc not found
The names of somefile.doc vary, but examples are WrdPrfctDat50.doc,
MSWordMac51.doc and Lotus123.doc. When I say 'a number', the above
sequence
of calls is repeated more than 180 times. The more files there are in
a
directory, the longer its going to take for VisionFS to [not] find a
particular file. Opening a .doc file instead doesn't experience the
same
delays as it interprets the file a "native" document, so it doesn't
look for
converter files.
The delay is coming from Word trying to open all the converter files.
Removing the text converter feature from Office did reduce the number
of
repetitions of the above sequence to about 20 in our tests, so you
might
want to try that to reduce the time it takes to open the .txt files.
The
best solution however, would be to not use Word 2000 to open
non-native
files, open the file from within an already running instance of Word
2000,
since it doesn't appear to search for converters in this fashion, or
go back
to using a previous version of Word that doesn't exhibit this problem.
Nothing can really be done from a VisionFS perspective.
In regards to your long file copy times, testing. shows that the
'preparing
to copy' phase involves Windows asking for details
(size/dates/attributes/...) of each file in turn. This then requires
VisionFS to stat() each file, which is an expensive operation. So, the
more
file you have in a directory, the larger number of stat() calls are
made,
the longer this is going to take to 'prepare to copy'.
There aren't really any standard times. Basically - the more files in
a
directory there are, the longer most operations are going to take.
There are
a number of other factors that could be involved here, such as network
speed, congestion and unnecessary protocol overhead, Unix
cpu/disk/memory
load, etc. Most versions of VisionFS have had some sort of improvement
in
this area in the past. There has been quite a lot of speed-up work
done for
VisionFS 3.1, due June/July, so I'd suggest you evaluate that release
when
it comes out.
Hope this help.
Cheers,
SCO Technical Support