Novell Netware Problem

Paul Naylor

unread,

Oct 14, 1994, 11:54:45 PM10/14/94

to

I am posting this article in regards to a message that appeared on the
Novell console. We've tried seeking help from Novell vendor and its
distributors but couldn't get any definite reply from them.

The message is "Waiting on a lock" under the connection information at the
Novell console. What we have done and observed in the following is ;

(1) Under the Console monitor in Novell, select Connection Information
(2) Highlight on one of the user, we will able to see the File Open activities
(3) Under normal condition, the status of the user is always: Normal
(4) When the user try to save a file, the status changes to "Waiting on a lock"
(5) When this "Waiting on a lock" appeared, the saving process was delayed
for about 2 - 3 mins, sometime up to 5 mins depending on the amount
of data. The performance in saving any file is expected to take a few
seconds or even less than a minute.
(6) Its affected the rest of the users who are accessing to the same
application and database files.

To give you a background of what is happening, this problem occurred
while people are working on an application developed by our own programmers
using Clipper 5.01. When they save a deal, there is a delay of 2 - 3 mins
(basically, it's just saving it to a file) as compared to a few seconds
in saving a deal previously.

Basically, what we need to know is from Novell point of view what triggered
off this "Waiting on a lock" message, apart from the application.
Specifically, what is "Waiting on a lock" from Novell, all about!!

Appreciate if anyone could help. Thanks.

posted by Paul <pna...@solomon.technet.sg> on behalf of Vincent Kuan.

Philip Chee

unread,

Oct 18, 1994, 11:45:42 PM10/18/94

to

In article <37njq6$i...@raffles.technet.sg> pna...@solomon.technet.sg writes:
>
>I am posting this article in regards to a message that appeared on the
>Novell console. We've tried seeking help from Novell vendor and its

>The message is "Waiting on a lock" under the connection information at the

>Novell console. What we have done and observed in the following is ;

> (1) Under the Console monitor in Novell, select Connection Information
> (2) Highlight on one of the user, we will able to see the File Open activities
> (3) Under normal condition, the status of the user is always: Normal
> (4) When the user try to save a file, the status changes to "Waiting on a> lock"
> (5) When this "Waiting on a lock" appeared, the saving process was delayed
> for about 2 - 3 mins, sometime up to 5 mins depending on the amount
> of data. The performance in saving any file is expected to take a few
> seconds or even less than a minute.
> (6) Its affected the rest of the users who are accessing to the same
> application and database files.

First of all, your programmers should try to RTFM first ;-)

Well here is what the a search on the Novell Folio help files using the
keyword "LOCKS" turned up:
----cut----
Parameters SET categories have parameters that can be
viewed or set. The bolded value given with
each parameter is the default setting.

Some categories have two types of parameters:
normal and advanced. Advanced parameters are
marked (adv).

File caching
Directory caching
File system
Communications
Memory
Locks
Transaction tracking
Disk
Miscellaneous

Locks Control how many open files each station can
have and how many total open files the OS can
handle.

They also control how many record locks each
connection can have and how many total record
locks the OS can handle.

These parameters control all three types of
locks: file, physical, and logical.

Maximum Record Locks Per Connection = 500
Limits: 10 to 10000
Maximum File Locks Per Connection = 250
Limits: 10 to 1000
Maximum Record Locks = 20000
Limits: 100 to 200000
Maximum File Locks = 10000
Limits: 100 to 100000

File locks A file lock secures the entire file and
prevents other stations from accessing the
file.

Physical locks A physical record lock controls data access
by multiple users. It prevents other users
from accessing or changing a range of bytes
(a record) in a file.

A physical record lock is enforced by the OS.
If another user tries to access a range of
bytes that is physically locked, the user is
denied access.

Logical locks A logical record lock also controls data access
by multiple users.

The application assigns a name to each section
of data to be locked. The application then
locks this name when it accesses the data.

A logical lock is not enforced by the OS;
it is enforced only to the extent that the
application checks the name each time it
needs access to data.

Maximum Record Locks Per Connection

Controls how many record locks a station can
use at one time.

Increase this parameter if an application
fails because it can't lock enough records.

Decrease this parameter if stations use too
many server resources.

Supported values: 10 to 10000
Default: 500

Maximum File Locks Per Connection

Controls how many opened or locked files a
station can use at one time.

Increase this parameter if an application
can't run because it can't open enough files.

An OS/2 workstation may need a higher
default than 250. You might need to increase
the number of file handles in the station's
SHELL.CFG file.

Decrease this parameter if stations use too
many server resources.

Supported values: 10 to 1000
Default: 250

Maximum Record Locks

Controls how many record locks the OS
can handle.

Increase this parameter if users have
problems running applications and receive
messages that not enough record locks are
available.

Decrease this parameter if users use too
many server resources.

Supported values: 100 to 200000
Default: 20000

Maximum File Locks

Controls how many opened or locked files
the OS can handle.

Use MONITOR to view the current number of
open files during peak usage.

Increase this parameter if the current
number of open files is near the default.

Decrease it to restrict the number of
available server resources.

Supported values: 100 to 100000
Default: 10000

Example 1. Type SET <Enter>

Screen display:
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄż
ł Setable configuration parameter categories ł
ł 1. Communications ł
ł 2. Memory ł
ł 3. File caching ł
ł 4. Directory caching ł
ł 5. File system ł
ł 6. Locks ł
ł 7. Transaction tracking ł
ł 8. Disk ł
ł 9. Miscellaneous ł
ł Which category do you want to view: ł
ŔÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄŮ

2. To select a category, type the number of the
category and press <Enter>.

3. Complete one of the following.
Ż To view the normal and advanced parameters,
type Y. Do not press <Enter>.
Ż To view only the normal parameters, press
<Enter>.

[logical level] The number (0 to 254) of logical record
locks TTS ignores before beginning to track
a transaction.

[physical level] The number (0 to 254) of physical record
locks TTS ignores before beginning to track
a transaction.

Notes A. You must set a logical level before setting
a physical level.

B. Leave a space between logical level and
physical level.

Example 1 To set TTS to ignore two logical and two
physical record locks before tracking
a transaction, type

SETTTS 2 2 <Enter>

Screen display:
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄż
ł Transaction Tracking Record Lock Thresholds ł
ł Logical level: 2 ł
ł Physical level: 2 ł
ŔÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄŮ

Example 2 To view your current setting, type SETTTS <Enter>

LOCK DELAY=number

Default: 1

This parameter determines the amount of
time (in ticks) the shell waits before
trying to get a lock.

When many users access a file at the same
time, the shell may be unable to gain
access before its allotted wait time. If a
workstation frequently receives error
messages when a file is requested, increase
the value of this parameter.

Note This number is used for lock types that
have no wait ability. For locks with a
wait ability, the wait time is calculated
by multiplying this parameter number by
the LOCK RETRIES number and then multiplying
by two. The resulting number is the time, in
ticks, the workstations will wait for a lock.

Parameters Ż Directory cache buffers
Ż Maximum number of open files
Ż Disk elevator size
Ż Memory for loadable modules
Ż File locks
Ż Routing buffers
Ż File service processes
Ż Router/server advertising
Ż Kernel processes
Ż TTS transactions
Ż Kernel semaphores
Ż Turbo FAT index tables

Advantages Implementing backup at the operating system
level provides two advantages:

Ż Transaction tracking performance improves with
TTS in the file server. Transactions are tracked
in the file server, where file writes are made.

Ż Database applications not designed for
transaction backout can have backout capability.

When a database application makes a physical
record lock or a logical record lock, it
"implies" that it is making a transaction. TTS
begins tracking the transaction.

When the application releases physical or
logical record locks, TTS infers that it
has completed a transaction.

Three kinds of database applications benefit
from TTS.

Volume mounting If the SYS volume is mounted after other
volumes, TTS scans the backout file on SYS at
mounting time to determine whether to back out
transactions on the volumes mounted before SYS.

(Back out any transactions made on volumes
where transactions were made after a server
failed but before SYS was mounted. Backing out
older transactions over more recent ones can
corrupt your database.)

If SYS is mounted before other volumes, TTS
scans the backout file on SYS as each additional
volume is mounted.

If TTS finds transactions that need to be backed
out on an additional volume, it initiates the
regular backout process.

TTS also holds all workstation record locks
until a transaction is completed.

Holding record Holding a workstation's record lock until a
locks transaction is complete prevents the disaster
that would result from the following situation:

Ż The application in Workstation #1 releases a
lock on a record before the transaction is
completed (written to disk).

Ż Workstation #2 locks and changes the same record
in file server cache memory (also before the
first transaction is completed).

Ż Workstation #1 fails and Workstation #2
completes its transaction.

Ż Because Workstation #1 failed, its transaction
is backed out, in this case over the transaction
that Workstation #2 completed.

TTS problems TTS keeps backout information in a special
system file, used only by the NetWare operating
system.

Whenever significant TTS events occur, a
description is logged in a TTS$LOG.ERR file
located in the root directory of the SYS
volume.

This file contains information you can use
in troubleshooting.

The TTS$LOG.ERR file contains information
about what happened with particular transactions
when a failure occurred; however, TTS does
not actually use this file for backing out
data.

This file shows when TTS was enabled or
disabled; it also gives pertinent dates,
times, file offsets, record sizes, record
data before the backout, and record data
from the original copy of the data.

By holding workstation record locks until
the end of a transaction, TTS avoids database
corruption that can occur when workstation
applications release record locks before
transactions are complete.

However, holding workstation record locks
until the end of a transaction allows for
the possibility of deadlocks between
workstations using some applications.

If the application uses records that can
be unlocked in the middle of transactions
to avoid deadlocks, then TTS introduces the
possibility of deadlocks for that application
(by holding record locks until the end of
a transaction).

A deadlock means that the two workstations
involved will hang.

To fix this problem, reboot both workstations;
TTS can still maintain database integrity
by backing out the transactions that were
in process.

Although rebooting the workstations isn't
desirable, it allows TTS to maintain the
integrity of the database.

If TTS is automatically disabled because the
SYS volume (the TTS backout volume) is full,
you must free up disk space on the SYS volume.

Under normal conditions, TTS requires only
1MB of disk space to track all transactions.

If you are adding or deleting large database
records (of more than 1MB each), you will
need to have free space on the SYS volume
equal to the size of the largest added or
deleted record.

Once you have freed up sufficient disk space
on the SYS volume, you can enable TTS with
ENABLE TTS.

Refer to the volume parameters described under
SET if you want to receive a warning when
the free space on the SYS volume is less
than you need for TTS.

If TTS is automatically disabled because the
server does not have enough free memory,
increase the memory available to TTS in one
of the following ways:

Unload server modules you don't need
currently (such as INSTALL or MONITOR).

You can also dismount volumes to free up
server memory.

Use ENABLE TTS again to see if you have
freed up enough memory for TTS.

If enough free memory is available, TTS
will be enabled; if not, it will remain
disabled.

Add more memory to the server.

TTS requires about 40 bytes to track each
transaction.

TTS can track up to 10,000 transactions; at
peak transaction load, the server would
require no more than 400KB of memory to track
transactions.

After you have installed sufficient memory,
the server will automatically enable
TTS when it boots.

If TTS is disabled (automatically or manually)
and then the server fails before all
transactions have been written to disk, the
information in the TTS backout file will
be unreliable.

You should not back out any transactions.

If TTS is shut down, the server can't
track when transactions are made, and if
allowed to back out any transactions (after
being enabled), could incorrectly overwrite
information that was changed after TTS was
disabled.

You can reduce the risk of this situation by
attaching a UPS to your server and disk
subsystems.

If the server fails, incomplete transactions
will be backed out when the server comes
up again.

However, transactions initiated before the
server failed may have been written to
server cache memory and not to disk.

Since a transaction isn't marked "completed"
by the operating system until it has been
written to disk, the server would back
out the transaction, even though it had been
"completed" according to the workstation
application.

If the "TTS Abort Dump Flag" is set to ON, a
copy of the original data from the transaction
will be written to the TTS$LOG.ERR file in the
root directory of the SYS volume.

You can compare this information (which would
have been restored to the database) with what
was entered at the workstation to determine
whether the information needs to be reentered
from the workstation.
----cut----

Roger Kresge

unread,

Oct 20, 1994, 3:24:00 AM10/20/94

to

From: roger....@labb.com <Roger Kresge>

Quoting a message from Paul Naylor:

>> The message is "Waiting on a lock" under the connection information at the
>> Novell console. What we have done and observed in the following is ;

>> Basically, what we need to know is from Novell point of view what triggered
>> off this "Waiting on a lock" message, apart from the application.

>> Specifically, what is "Waiting on a lock" from Novell, all about!!

You've got a fun problem there, Paul. Here's what I suspect: You're
using VLM v1.10 from the workstation(s) involved. There's a data
reliability feature in that version of the VLMs that's implemented
with a NET.CFG parameter called TRUE COMMIT (don't have my manual at
hand, so you need to look this one up). Turns out that it defaults
to a setting that absolutely waits until the server verifies that
data has been written to disk before releasing the lock. Earlier VLM
versions, and NETX, all assumed the server would take care of the
write and released the lock as soon as the data had been sent to the
server.

- Roger Kresge, ECNE/CNI
---
. SPEED 1.40 [NR] . How can you tell a Democrat/Liberal/Clinton is lying?

----
Origination - Lancaster Area Bulletin Board - (717) 394-1357
Internet Mail and News feeds provided by ClarkNet - Gateway to the Internet
For info call (410) 730-9768 and login as "guest"