Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

VisonFS3.00.925 and WinWord2000 trouble

5 views
Skip to first unread message

Peter

unread,
Apr 14, 2000, 3:00:00 AM4/14/00
to
We use VisionFS 3.00.925 on a server with Ppro200 (UW213) and a client
with Win98SE. In a directory on /home2/a/ is stored following file:
-start:::
1234567890
abcdefg
ABCDEFG
1
2
3
4
5
6
7
8
9
0
-end:::
wc of_this_file: 13 13 47,
size of it shown under Win98SE 47 Bytes.
Now open it using notepad takes 1 sec, that's OK,
under Wordviewer97 2 sec, OK too,
under Word2000 it takes over 1 Minute!!!
Monitoring the server with rtpm shows u+s-time 100% and u-time >=90%
most of the time. After data is in word2000 both are 2%.
Under this terms it is unpossible to use VisionFS, all the clients
want sharing doc-data on the server.
Who is able to give us HELP, we really need it!!! :=((((
Installation must be OK at end of the mounth! otherwise SCO go home
und NT is comming in (but not from us :>(( ).
Cheers Peter

Gilles SIMON

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to
try Samba (Now supported by SCO).

--
Gilles SIMON
gil...@wanadoo.fr

mojo_...@my-deja.com

unread,
Apr 17, 2000, 3:00:00 AM4/17/00
to
In article <38f72b0c...@news.btx.dtag.de>,

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.

Peter

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to

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

- bill -

unread,
Apr 18, 2000, 3:00:00 AM4/18/00
to

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

Peter

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Hi, that's new (but not good!):
A1. Opening test.txt, placed on host, via Word2000: 22 seconds.
A2. Saved it out of word2000 as .doc to the host (same directory where
test.txt is) 20 sec.
A3. Closed word2000 and opened the test.doc: 10 seconds
#
B1. as A1
B2. With still open Word2000 opened a 2.copy of test.txt: 8 seconds!!!
#
C1: I tried on an other maschine Esker TUN NFS Version 9, in the same
manner as my original testing, UND with the same bad result!!! No
visonfs installed there!
#
D1: copied test.txt from host to client (P2-300, WIN98FE) and open it
with word2000: 5 seconds.

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

- bill -

unread,
Apr 19, 2000, 3:00:00 AM4/19/00
to
Unless I missed it, you did not try a network open from a MS host.
did you. If not, what is the result ?

Peter

unread,
Apr 20, 2000, 3:00:00 AM4/20/00
to
On Wed, 19 Apr 2000 10:04:02 -0400, - bill - <bi...@TechServsys.com>
wrote:

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

Peter

unread,
Apr 24, 2000, 3:00:00 AM4/24/00
to
Hallo,
my problem still exists and over easter i tried the following test, it
shows a point - i think - in with the trouble will be:
First, i created a separate directory and maked it under visionfs as
an own share with "opportunistic locks".
Then i copied ONE of my test.txt file in it.
Opening it with word2000 (klick on the icon, start word2000 and
display the data of test.txt) takes 15 seconds.
Next, i created in this directory 100 copies of test.txt, called
A0-A99.txt, opening time of test.txt now: 23 sec.
Again copied 200 ones of test.txt as B0-B199.txt, time now: 36 sec.
And last copied 300 ones of test.txt as C0-C299.txt. So now i have a
total of 601 files of test.txt in the directory: opening time for
test.txt with word2000 now: 55 seconds!
On my original startpoint of the problem and my cry for help in the
NG, in the testing directory where 717 entries of (different) *.txt
files (but all about 50 bytes). So you see, time will growth over 1
minute.
I than did an other test: over visionfs i selected everything in the
directory and copied it into in other one:
The process shows: preparing for copy... : 5.5 minute,
copying... : 5.5 minute. Total 11
minutes. Are this normal times? Oh my head it's like under a hammer.
Cheers Peter

Christopher Cox

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
> Installation must be OK at end of the mounth! otherwise SCO go home
> und NT is comming in (but not from us :>(( ).


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

Peter

unread,
Apr 25, 2000, 3:00:00 AM4/25/00
to
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
Cheers Peter

On Tue, 25 Apr 2000 11:29:08 GMT, "Christopher Cox" <co...@urec.net>
wrote:

mojo_...@my-deja.com

unread,
Apr 27, 2000, 3:00:00 AM4/27/00
to

> >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

mojo_...@my-deja.com

unread,
Apr 27, 2000, 3:00:00 AM4/27/00
to

> 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?

Peter

unread,
May 2, 2000, 3:00:00 AM5/2/00
to

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

0 new messages