Summer '87 Question 
Author Message
 Summer '87 Question

I have a large S '87 application that has been running for the last 8
years on Novell networked dos workstations.  Many of the workstations
have been "upgraded" to pentium machines now running WinNT 4.0.  These
applications have run fine for years under dos, but under NT we have
seen some erratic data problems.

These problems range from data not being written to disk, to most
recently, duplication of data written to disk.  I know that the NTVDM
may not recognize all of the same interupt commands, but is there a way
to make it perform a disk write?

Also have experienced an erratic hang when shelling out using the
Blinker SWPRUNCMD within an NT window.  I've read in Blinkers
documentation that the memory allocated for a secondary program will
remain allocated until the primary program terminates.  This was not a
problem with the 386 machine running dos with emm386.  Any ideas for
this problem as well, or I may just have to re-write and rethink how the
same task can be accomplished without being called from the application.

We're running WinNT V4.0 workstation on a Novell Netware 4.1 network
with Novell's Intranetware Client for Window NT.  Libraries include
dClip, and Funcky if that matters, linked with Blinker vers 5.0.

Thanks for the help -

Bill



Sat, 17 Mar 2001 03:00:00 GMT  
 Summer '87 Question

Quote:

> I have a large S '87 application that has been running for the last 8
> years on Novell networked dos workstations.  Many of the workstations
> have been "upgraded" to pentium machines now running WinNT 4.0.  These
> applications have run fine for years under dos, but under NT we have
> seen some erratic data problems.

> These problems range from data not being written to disk, to most
> recently, duplication of data written to disk.  I know that the NTVDM
> may not recognize all of the same interupt commands, but is there a way
> to make it perform a disk write?

The solutions is very easy: make an 'commit' after every update.

Quote:
> Also have experienced an erratic hang when shelling out using the
> Blinker SWPRUNCMD within an NT window.  I've read in Blinkers
> documentation that the memory allocated for a secondary program will
> remain allocated until the primary program terminates.  This was not a
> problem with the 386 machine running dos with emm386.  Any ideas for
> this problem as well, or I may just have to re-write and rethink how the
> same task can be accomplished without being called from the
> application.We're running WinNT V4.0 workstation on a Novell Netware 4.1
> network with Novell's Intranetware Client for Window NT.  Libraries
> include dClip, and Funcky if that matters, linked with Blinker vers 5.0

 There are some problem with the update from funcky 2.01 to the next version
(2.2 I think) , when you execute some funcions. And also I have found a bug
when I execute gete("path") and the length of "SET PATH" variable is grater
than 128 bytes.: always crahs the system.

Good luck,

--
**************************
Ramon Prior i Ti

GRN Serveis Telemtics, SL
Pla?a de l'Assumpci, 35
17005 Girona (Sant Narcs)
http://www.grn.es
Telfon: 972 - 23 00 00
Fax: 972- 40 11 85

Quote:
>>> IwTLDxC <<<

**************************


Sun, 18 Mar 2001 03:00:00 GMT  
 Summer '87 Question
We have S87 apps running under Win 95 and have had a terrible time with
indexes.  They
always seem to be out.  One is on Win 95 peer to Peer networking and another
on an NT server.
It seems that our S87 apps run great single user or under light load on
Multi user.  But under heavy
load on an NT/95  environment the indexes fail.

Have you expenienced this?

Quote:

> I have a large S '87 application that has been running for the last 8
> years on Novell networked dos workstations.  Many of the workstations
> have been "upgraded" to pentium machines now running WinNT 4.0.  These
> applications have run fine for years under dos, but under NT we have
> seen some erratic data problems.

> These problems range from data not being written to disk, to most
> recently, duplication of data written to disk.  I know that the NTVDM
> may not recognize all of the same interupt commands, but is there a way
> to make it perform a disk write?

> Also have experienced an erratic hang when shelling out using the
> Blinker SWPRUNCMD within an NT window.  I've read in Blinkers
> documentation that the memory allocated for a secondary program will
> remain allocated until the primary program terminates.  This was not a
> problem with the 386 machine running dos with emm386.  Any ideas for
> this problem as well, or I may just have to re-write and rethink how the
> same task can be accomplished without being called from the application.

> We're running WinNT V4.0 workstation on a Novell Netware 4.1 network
> with Novell's Intranetware Client for Window NT.  Libraries include
> dClip, and Funcky if that matters, linked with Blinker vers 5.0.

> Thanks for the help -

> Bill

--
Thomas O. Witt,  President
Computer Services and Consultants
20 East Piccadilly St.
Winchester, Va.  22601-4869

"Your Source for Software"

540-665-0800
540-665-0897 fax



Sun, 18 Mar 2001 03:00:00 GMT  
 Summer '87 Question

Quote:


> snip

> > These problems range from data not being written to disk, to most
> > recently, duplication of data written to disk.  I know that the
> NTVDM
> > may not recognize all of the same interupt commands, but is there a
> way
> > to make it perform a disk write?

> The solutions is very easy: make an 'commit' after every update.

Ramon,

Thanks for your response.  I'm presently using the 'commit' command, but
it apparently does not force a disk write under the NT dos window.  I
was hoping someone might have another technique to force NT to write to
disk.  I'm guessing it doesn't work because NT creates a 'virtual' dos
window and handing the I/O differently.

Bill Silva



Sun, 18 Mar 2001 03:00:00 GMT  
 Summer '87 Question

Quote:



> > snip

> > > These problems range from data not being written to disk, to most
> > > recently, duplication of data written to disk.  I know that the
> > NTVDM
> > > may not recognize all of the same interupt commands, but is there a
> > way
> > > to make it perform a disk write?

> > The solutions is very easy: make an 'commit' after every update.

> Ramon,

> Thanks for your response.  I'm presently using the 'commit' command, but
> it apparently does not force a disk write under the NT dos window.  I
> was hoping someone might have another technique to force NT to write to
> disk.  I'm guessing it doesn't work because NT creates a 'virtual' dos
> window and handing the I/O differently.

> Bill Silva

Bill,

I guess the brute force method of closing the dbf file and then
reopening and returning to the previous record position would be out of
the question?

Regards,

Ross McKenzie
ValuSoft
Melbourne Australia



Mon, 19 Mar 2001 03:00:00 GMT  
 Summer '87 Question
I have been researching this problem with Microsoft Technet and have only
found 2 relevant documents. The documents refer to NT 3.51 but are relevant
to NT 4 as well.

- Kevin

<<excuse the large amount of text - but as with anything Microsoft, its
bloated... :) >>

======================================================================
PSS ID Number: Q134637
Article last modified on 12-18-1997

2.6a

WINDOWS

======================================================================
---------------------------------------------------------------------
The information in this article applies to:

- Microsoft FoxPro for Windows, version 2.6a
---------------------------------------------------------------------

SYMPTOMS
========

Users may receive an "Error reading drive <drive name>" message, or a
"System error: Network error on drive <drive name>" message when trying to
access a remote file on a Windows NT server or a workstation acting as a
server.

CAUSE
=====
Microsoft Windows NT caches the file handles (RFCBs) associated with
files it has opened on behalf of a client request. Although write
requests proceed normally, close requests are acknowledged by the server
but buffered from the file system. This is intended to optimize response
time to repeated open/close operations performed by clients.

Opportunistic Locking (oplock) optimization is a logical extension of
the way a client caches its own file close request and relies on the
server to arbitrate future requests for file access by other clients.
This optimization may fail to work correctly depending on how the file
has been opened by the application.

RESOLUTION
==========

WARNING: The information in this article has not been confirmed or tested
by Microsoft. Some or all of the information in this article has been taken
from unconfirmed customer reports. ANY USE BY YOU OF THE INFORMATION
PROVIDED IN THIS ARTICLE IS AT YOUR OWN RISK. Microsoft provides this
information "as is" without warranty of any kind, either expressed or
implied, including but not limited to the implied warranties of
merchantability and/or fitness for a particular purpose.

These errors have been resolved by using two different methods, each of
which involve using the Registry Editor on the computer running Windows NT
to manually disable this optimization by changing default parameters in the
Registry.

MORE INFORMATION
================

WARNING: Using the Registry Editor incorrectly can cause serious, system-
wide problems that may require you to reinstall Windows NT to correct them.
Microsoft cannot guarantee that any problems resulting from the use of
Registry Editor can be solved. Use this tool at your own risk.

Method 1:

The EnableOplocks startup parameter specifies whether the server allows
clients to use oplocks on files. The default setting is 1 (true). Oplocks
enable a significant performance enhancement but have the potential to
cause lost cached data on some networks, particularly wide-area networks.

EnableOplocks is found in this path:

   \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
   \LanmanServer\Parameters

With the Registry Editor, change the EnableOplocks parameter to 0 (false).

Method 2:

CachedOpenlimit controls the number of files that are cached open for
optimization. Disabling this optimization and not caching open files has
succeeded in alleviating these errors with FoxPro. The CachedOpenLimit
parameter is located in the following key:

   \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
   \LanmanServer\Parameters

If CachedOpenLimit exists, change the parameter to 0. If it does not exist,
add it as follows:

   Value Name: CachedOpenLimit
   Data Type:  REG_DWORD
   Data:       0

Method 3:

CacheFileTimeout controls duration of time the Cache manger holds the file
open after an application has requested that it be closed. The response
time for closing the file can be enhanced by reducing the CacheFileTimeout
value. The CacheFileTimeout parameter is located in the following key:

   \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
   \LanmanServer\Parameters

If CacheFileTimeout exists, change the parameter to 1. If it does not
exist, add it as follows:

   Value Name: CacheFileTimeout
   Data Type:  REG_DWORD
   Data:       1

   or disable Opportunistic locking in the location

   UseOpportunisticLocking     REG_DWORD

   Range: 0 or 1
   Default: 1 (true)

   Indicates whether the redirector should use opportunistic-locking
   (oplock) performance enhancement. This value entry should be
   disabled only to isolate problems.

REFERENCES
==========

For more information please see the following articles in the Microsoft
Knowledge Base:

   ARTICLE-ID: Q102967
   TITLE     : REG: Server Service Entries, PART 1

   ARTICLE-ID: Q124916
   TITLE     : Some Client Applications Fail When Writing to Windows NT

======================================================================
Keywords          : FoxWin FxnetworkWinnt
Version           : 2.6a
Platform          : WINDOWS
Issue type        : kbprb
============================================================================
=
Copyright Microsoft Corporation 1997.

============================================================================
=

PSS ID Number: Q124916
Article last modified on 11-19-1997

3.5

WINDOWS

======================================================================
----------------------------------------------------------------------
The information in this article applies to:

- Microsoft Windows NT Workstation version 3.5
- Microsoft Windows NT Server version 3.5
----------------------------------------------------------------------

SYMPTOMS
========

Some applications running from a Windows for Workgroups or LAN Manager
client fail when they attempt to write to a file located on a Windows NT
version 3.5 server (whether it is a Windows NT Server version 3.5 or a
Windows NT Workstation version 3.5 machine acting as the server). The
application may report this error in various ways, such as reporting a
sharing violation, reporting that they cannot write the file, and so forth.
These same applications, however, do not fail in this manner when they
write a file to a Windows NT version 3.1 server.

CAUSE
=====

There is an optimization in Windows NT version 3.5 which controls whether
or not a file is actually closed on the server when requested to do so by
the client. This optimization is controlled by the Registry parameter,
CachedOpenLimit. If the server owns an oplock on a file when the client
closes it, although the server will return the Close Server Message Block
(SMB) response indicating that the file has been closed, it will keep the
file open locally (that is, it removes the RFCB, but maintains the LFCB and
does not issue the local NtClose() request), on the assumption that the
client may soon reopen the file. If the client does reopen the file, this
greatly reduces the time required to respond to the request.

This optimization may fail to work correctly depending on how the file has
been opened by the application. In many cases this can only be determined
correctly by analyzing a trace of the network traffic between the client
and the server while running the application. However, a quick test can be
performed by disabling this optimization and not caching open files. To
disable caching open files on the server as a test, follow these steps:

   WARNING: Using Registry Editor incorrectly can cause serious, system-
   wide problems that may require you to reinstall Windows NT to correct
   them. Microsoft cannot guarantee that any problems resulting from the
   use of Registry Editor can be solved. Use this tool at your own risk.

   1. Start the Registry Editor (REGEDT32.EXE)

   2. Find the following key:

         \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
            \LanmanServer\Parameters

   3. Add the following entry:

      Value Name: CachedOpenLimit
      Data Type:  REG_DWORD
      Data:       0

      NOTE: The default value for CachedOpenLimit is 5 remote file control
      blocks (RFCBs) per connection.

   4. Exit the Registry.

   5. Shutdown and restart Windows NT.

WORKAROUND
==========

You can work around this problem by using the above directions to disable
the CachedOpenLimit optimization.

STATUS
======

Microsoft has confirmed this to be a problem in Windows NT version 3.5. We
are researching this problem and will post new information here in the
Microsoft Knowledge Base as it becomes available.

Additional query words: wfw wfwg prodnt 3.50 access denied share locked
foxpro fox pro setup wizard oplocks oplock
======================================================================
Keywords          : nt16ap ntfilesys kbnetwork
Version           : 3.5
Platform          : WINDOWS
============================================================================
=
Copyright Microsoft Corporation 1997.

Quote:

>I have a large S '87 application that has been running for the last 8
>years on Novell networked dos workstations.  Many of the workstations
>have been "upgraded" to pentium machines now running WinNT 4.0.  These
>applications have run fine for years under dos, but under NT we have
>seen some erratic data problems.

>These problems range from data not being written to disk, to most
>recently, duplication of data written to disk.  I know that the NTVDM
>may not recognize all of the same interupt commands, but is there a way
>to make it perform a disk write?

>Also have experienced an erratic hang when shelling out using the
>Blinker SWPRUNCMD within an NT window.  I've read in Blinkers
>documentation that the memory allocated for a secondary program will
>remain allocated until the primary program terminates.  This was not a
>problem with the 386 machine running dos with emm386.  Any ideas for
>this problem as well, or I may just have to re-write and rethink how

...

read more »



Mon, 19 Mar 2001 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Summer '87 Question

2. Summer '87 User with General Question

3. Comms Port Question from a humble Summer '87 programmer

4. Summer '87 App doesn't remote print

5. Win '95/Summer '87

6. Can't open xxxx.DBF error in Summer '87

7. Clipper Summer'87

8. Summer' 87 Y2K bug

9. Looking for Books For Clipper Summer '87

10. Clipper Summer'87 cpu load 100%

11. Clipper rookie using Summer '87, PLink86 and Blinker 1.11

12. Summer '87 and Win98

 

 
Powered by phpBB® Forum Software