************************************* * * * DB/C Newsletter * * June 1997 * * * ************************************* News and Comments In this month's article, Jamie Findlay discusses several problems that have occurred with DB/C 9.1 for MS-DOS and DB/C 9.1 for Windows 95/NT when running in a local (or wide) area network. Hopefully, this will help you avoid these problems. The comp.lang.plb newsgroup has again failed to be approved as a USENET newsgroup. The vote was 60 in favor, 16 opposed, and 14 spoiled ballots. Unfortunately, 100 more yes votes than no votes are required. Maybe somebody will try again in 6 months to get it established. PLEASE MAKE A NOTE: The zip code of Subject, Wills & Company in Oak Brook, Illinois has changed to 60523. don.wills@swc.com ******************************************************************************* DB/C and Networks by Jamie Findlay Novell Netware Problems Problem 1: Deletion of the user that is owner of DB/C data files. The result of this action will eventually cause I 706 or I1769 errors (write errors). The problem is that when a 4096 byte allocation unit is required to extend the file, Netware can not look up the allocation rights for the owner because the owner no longer exists. The result is Netware returns an error that appears to be an out of disk space error even though there is plenty of disk space. The NDIR command will show the owner of the file as being invalid. The FLAG /NAME= command can be used to correct this problem. Problem 2: File corruption of output files when using the DB/C utilities or exclusively opened files in DB/C. This problem is a workstation level problem when using NETX or VLMs. It is uncertain when the problem began with NETX, but it should be assumed to exist on all workstations. The best description of the problem is that the Netware workstation tries to buffer the disk output. The problem occurs when the disk output overlaps, so that some of the bytes of the newer write become an update on a previous write. My understanding is that when the writes finally make it disk, the writes are not in the same order as DB/C had performed them in. Thus, the updated bytes are the older bytes and not the newer bytes. Typical examples are 0xFBs (DB/C EOF) in the middle of the file and DB/C debugger failing because of invalid .DBG or out of memory errors. The solution when using NETX or VLMs is to add a line to the NET.CFG file. The line is: cache buffers = 0 If you do not have a NET.CFG file, create one using any MS-DOS text editor in the same directory that is the current directory when the Netware shell is loaded. NOTE: this problem has not gone away and still exists even with the Novell Netware's version of Win95 Client32. If Netware's Client32 is being used, go into the advanced options and turn off all caching. Problem 3: Poor performance when using VLMs with DB/C. Novell had several problems with VLMs. The most noticeable, was with the packet burst algorithm that could accidentally reduce the packet size and add a delay between packet transmission. This was corrected in the second version of 1.20A. We recommend the latest version which is 1.21 (5-14-96). Problem 4: Transaction Tracking System (TTS) and implicit transactions cause problems with the DB/C runtime. When TTS is used with an application not designed for transaction backout, an implicit transaction algorithm is used for transaction backout. DB/C was not written to incorporate transaction backout and falls victim to the implicit transaction algorithm. TTS incorrectly assumes a transaction completes after DB/C reads/writes to a file while a record/file lock is active. This may cause a TTS Holding Lock to occur on a record in the file, which will prevent any other DB/C users from reading the record. Those users will get an I1768 error (unable to read). Therefore, we recommend that all DB/C data files have transaction tracking turned off. This can be accomplished with the FLAG -T command. There is also an elusive I1771 error (unable to lock) that gives a Netware error of 162 (read file with record locked). I suspect that TTS may be the cause for this error also. Problem 5: Change from NETX to VLMs causes SPLCLOSE S to stop working. This problem only applies to the MS-DOS version of DB/C. In order for DB/C to submit a file to a Netware spooler, it uses an old Netware function that has been phased out with the introduction of VLMs. This is unfortunate, because the old method is much faster than the new, preferred method of copying the file into a temporary file created by the Netware print queue. DB/C 9.1 attempts to submit the spool file using the old method and if that fails, it then uses the preferred method. The problem is the target between the old and preferred method are different. With the old method, the queue was specified with a number, i.e. SPLCLOSE S,P=0. This would cause the spool file to be printed to the print queue that was associated with spool number 0. The preferred method specifies a Netware queue name, not a number (e.g. SPLCLOSE S,P=PRINTQ1). Problem 6: Running 2 or more copies of DB/C for MS-DOS on one workstation using a Windows client causes various problems. The problem is that when DB/C uses Netware locking on a Netware network may cause I1671 or I1771 errors (unable to lock) when two applications try to lock the same byte range within a file. This problem only applies to the Netware type of locks. The standard MS-DOS type locks will work correctly. DBC_MODE=SYSLOCK can be used to force DB/C to use the MS-DOS locks. This should be set if multiple versions of DB/C will be executed from the same workstation using Windows. Problem 7: Netware broadcast messages cause problems executing the MS-DOS version of DB/C under MS-DOS or Windows 3.x. A poorly timed broadcast message can disable access to a data file if the broadcast message occurs at the same time a DB/C application has the file locked, explicitly with a FILEPI or implicitly with an I/O statement such as READKS. This broadcast message prevents the DB/C application from releasing the lock, thus preventing any other users from accessing the file. The other users will get I1671 or I1771 errors (unable to lock) after the lock attempt time-outs, usually 2 minutes. Any message that stops DB/C from executing need to be prevented. The Netware command CASTOFF can be used to reject broadcasts from other stations. The utility WHOHAS available on our FTP site in the /pub/misc/util directory at ftp.swc.com can be used to determine the owner of a lock on a Netware file. The WHOHASX utility is a newer version that supports wild cards for the file specification. These are just some of the more common problems people have had with DB/C and Netware. We recommend people using Netware 3.x should be running Netware 3.12 and people using Netware 4.x should be running 4.11. If the Novell Netware Client32 is being used with Windows 95, then the latest version available from Novell should be used. Generic PC Network Problems The number of problems experienced with other PC networks has been smaller. One typical problem we hear of is a user getting I1671 errors (unable to lock). This is usually caused by SHARE not being loaded. Some networks require SHARE to be loaded to lock a file on a local drive, (e.g. C:). This can be easily resolved by loading SHARE from AUTOEXEC.BAT. There is a common problem when running the MS-DOS version of DB/C under Windows 3.x in a network environment. The problem happens when the running DB/C application is put into the background. It stops executing. If this occurs while a lock is being held by DB/C (a FILEPI is active), then the symptoms can be similar to the Netware Problem 7 described above. If it is possible for DB/C to be placed in background on Windows 3.x, then a PIF must be used to start DB/C and the PIF will need to be edited so that a background priority is specified. Usually a background priority of 50 and a foreground priority of 100 is sufficient for most situations. Microsoft Windows Network Problems Windows NT Server, Windows 95 Peer to Peer, and Windows for Workgroups are suspected of creating several problems for some DB/C users. Unfortunately, we have not been able to duplicate the reported file corruption problems the users have experienced. We have been able to identify and recreate the following two problems. Problem 1: Opportunistic locking causes file corruption in a multi-user environment. We have been able to reproduce a situation where 2 Windows 95 clients attached to an NT Server 3.51 can cause an index file to be corrupted within 10 seconds. The problem was resolved when we disabled opportunistic locking. The NT Server default is for opportunistic locking to be on. This server registry entry EnableOplocks can be found in the documentation for Server Service Entries. Oplocks are a significant performance enhancement, but have the potential to cause lost cached data on some networks, particularly wide-area networks. To turn off Oplcosk, set EnableOplocks to 0 using the Registry Editor. Problem 2: This problem occurs while creating an existing file that resides on an NT Server using a Windows NT Workstation and DB/C for Windows 95/NT. The problem occurs when the new file is shorter than the old file. This can cause the new file to have an invalid EOF character and garbage character(s) at the end of the file. The problem can also create an invalid .DBC file, which may produce a C 102 error (invalid program) or a C 107 error (out of memory). The problem was traced back to the WIN32 API call CreateFile() when the TRUNCATE_EXISTING option was used. DB/C and the utilities were changed to no longer use this option. This problem only exists if both NT Server and Workstation are being used. It was not a problem for Windows 95 clients or Netware networks. This problem was corrected April 3rd, 1997. The DB/C utilities incorporating this change are available at ftp.swc.com in /pub/dbc91. Contact your DB/C supplier if the DB/C runtime needs to be replaced. If you are running Windows NT Server version 3.51, make sure you have updated the software to Service Pack 5. If you are running NT Server 4.0, make sure you have updated the software to at least Service Pack 1. If you are installing Service Pack 2, make sure you choose the install UNINSTALL option, because several users have encountered problems with Service Pack 2 that are unrelated to DB/C. If you are running a Windows 95 client with NT 4.0 Server, you need to install the Windows 95 client update which comes on the NT 4.0 Server CD-ROM. This fixes several problems including some performance problems. ******************************************************************************* DB/C Class Schedule Class Date Location DB/C 9 Fundamentals June 10-12, 1997 Oak Brook, IL For information, contact Judi Tamkevic at: voice 630.572.0240 fax 630.572.0390 email dbc@swc.com ******************************************************************************* Subscribing to the DB/C Newsletter If you don't already have the DB/C Newsletter delivered to your email address and would like to have it emailed to you once a month, just send an email message to 'majordomo@swc.com' and put the line 'subscribe dbcnews' in the body of the email message (omit the ' characters). The newsletter will be delivered to the email address from which the message was sent. *******************************************************************************