![[Company Logo Image]](images/logo.gif){kind=logo}
![[Home]](images/bhome.gif){kind=small}
![[What's New]](images/bnews.gif){kind=small}
![[Feedback]](images/bfeed.gif){kind=small}
![[Documentation]](images/docs.gif){kind=small}
The term "10030 errors" describes a class of events that are not actually errors, but are rather an indication that a program has been blocked from continuing by the actions of another workstation, task, or user. In this, 10030 errors are similar in nature to "record locks" and should (in theory) eventually clear themselves and allow normal processing to continue.
In practice, however, the 10030 error message does not appear on the user's screen until such time as the program has been blocked for a time that is considered to be "too long" and thus the occurrence of this message on a user's screen indicates that something bad is happening on the user's network as a whole.
Some operations performed by a program need to be "atomic" and "exclusionary." That is, it is necessary to ensure that no other workstations or task on a network perform a similar operation simultaneously because the two operations would interfere with each other.
An easily understood example of this is the process of updating a key file. In some key file updates, it is necessary to change index information at several places (possibly widely separated) within the key file. It is inappropriate for any other workstation to read or write to that key file between the time that the first update information is written and the time that the last update information is written. During this time the key file is in an inconsistent and unstable state and valid update operations by another workstation could result in invalid results. Therefore, all such operations are blocked.
If the workstation asserts a blocking request and is in some way prevented from releasing the block, all other workstations on the network will stop if/when a conflicting operation occurs in the program flow and a 10030 error message will show up at the top of the screen. There are several ways in which a workstation may be prevented from releasing a block:
A) The workstation could be turned off or lock up (static discharge, etc.) while running.
B) The window in which the application is running could be killed by user intervention.
C) A system or network error could occur resulting in an "Abort, Retry, or Fail?" type of system intercept (printer problems, diskette drive empty, network problems, etc.).
D) LBASIC could be running in a Dos box that does not permit background execution and the user may have switched to another window.
E) A program defect in LBASIC or SBW may exist.
There are presently two types of 10030 errors.
1. Open blocks
2. File blocksOpen blocks are asserted to ensure exclusionary access to portions of file OPEN and CLOSE operations. An open block is asserted by locking a semaphore named "file.ext/volid/xOP" where "file.ext" is the file name with extension, "volid" is the directory path from the root of the drive and "x" is the drive letter that contains/will contain the file.
An open block can be identified because the error message at the top of the user's screen will begin with the text "[Open busy (10030) -- waiting..." and may or may not identify the workstation that has blocked the network.
File blocks are asserted to ensure any other exclusionary access to file operations. A file block is asserted by locking a semaphore named "file.ext/volid/xCR" where "file.ext" is the file name with extension, "volid" is the directory path from the root of the drive and "x" is the drive letter that contains the file.
A file block can be identified because the error message at the top of the user's screen with begin with the text "[File busy (10030) waiting...]" and then identify the file being blocked by its file name portion.
If your users are running a system that processes semaphores via either the "SuperB Semaphore Server" (SBSERVER) or via disk-based semaphore emulation you may use an available tool to view the active semaphores and locate the semaphore described above.
For SBSERVER users, the SBSERVER program itself, which runs on one of your user's server systems, permits the viewing of the network's active semaphores. Use the "Connection Detail" screen (activated by pressing the "D" key) and cycle through all of the active connections by repeatedly pressing the "D" key which causes the display of the next connection each time it is pressed. When the 10030 block semaphore is found, the workstation ID of the displayed connection can be identified by looking in the semaphore list for a semaphore of the form "WSID_xx". The "xx" from "WSID_xx" identifies the workstation ID.
For disk-based semaphore emulation users, the SEMLIST.EXE program is provided to view the semaphore tables. It is necessary to run this program from a Dos workstation or in a Windows Dos box. Set the HD parameter in the Dos environment to match that which would be used to run your application and start the SEMLIST.EXE program. At present, the SEMLIST.EXE program shows all active semaphores undifferentiated by workstation. Locate the 10030 block semaphore in the list and read the WSID that has asserted it from the WSID column of the list. Since all semaphores are displayed there may be too many to fit on a single screen and it will then be necessary to use the paging command (executed by pressing the "P" key) to page through the list of semaphores in order to find the 10030 block semaphore.
First, check to see if the user has an LBASIC running in a background Dos box that does not permit background execution. If so, just bringing the Dos box to the foreground will release the block and permit the rest of the network to proceed. If you encounter this, please be sure to change the "enable background execution" option so that it doesn't happen to you again!
If the workstation that asserted the block is still (apparently) running correctly, it should be possible to clear the block by simply exiting your application to Dos on that workstation. In some circumstances involving Novell NetWare™ it may be necessary to reboot and relogin that system.
Note that the workstation that caused the 10030 error should not be blocked with a 10030 of the same type and file itself and should be running normally. If this is the case, you have probably encountered an LBASIC or SBW program defect and the circumstances should be reported (if possible) to SuperB Software, Inc.
If the workstation that asserted the block is frozen try to determine why this happened.
If the workstation is turned off or not running the application see if the user turned off the system or killed the application window without exiting your application in a normal manner.
SBSERVER.EXE has a built-in command to clear all semaphores asserted by a particular workstation. After determining that the workstation that caused the 10030 error locked up, was turned off, or was stuck at a system/network error, you may wish to clear the semaphores that it once asserted and has now orphaned. This may be accomplished by pressing the <Esc> key on the SBSERVER.EXE window (on the server) and entering the command "CLEAR nn" where "nn" is the workstation ID that has asserted the 10030 block.
Note that you should be sure that you have identified the proper machine and that no one is using that workstation ID improperly on another system on the network because clearing the semaphores asserted by an active workstation can cause problems.
The same sort of clearing operation can be performed on a NetWare system once the workstation is identified from the workstation ID and the NetWare connection is identified from the login name of the user logged-in there. See documentation for the NetWare "CLEAR STATION" command and/or delete it from the MONITOR connection list.
Note that your do NOT want to issue a "CLEAR STATION" command using the workstation ID but need to use a NetWare connection number.
There is presently no similar (simple) way to clear the semaphores of a single workstation ID for users using disk-based semaphore emulation.
You may be able to use the LBASIC and SBW command line parameter "-W" to force your workstation ID to be allowed and clear the existing semaphores. This parameter forces LBASIC and SBW to permit the use of a workstation ID that appears to be already in use.
The "-W" parameter will work on SBSERVER.EXE networks and disk-based semaphore emulation network to clear both the existing workstation ID and all of its associated semaphores.
It is not clear at the time this document was prepared whether the "-W" parameter is completely effective on NetWare networks and its use thereon is not recommended as a remedy for 10030 errors.