Re: NT and 2.1.6 client problems continue (divide by zero pr

For anyone who is experiencing a divide-by-zero error with the 32-bit Windows
2.1.0.6, this is in all likelihood the problem reported in APAR IC16240. This
most commonly occurs when a music CD is in the CD-ROM drive, although it may
also happen due to other circumstances.

What's happening is that ADSM issues an operating system call to obtain
information about each drive on the system. The call returns information such
as:

Total allocation units
Available (i.e. unused) allocation units
Sectors per allocation unit
Bytes per sector

With this information, ADSM can calculate the drive's total capacity, and how
much of that capacity is used. From there, it determines the percent
utilization of the drive by dividing used space over total capacity.

If the total allocation units are reported back by the operating system as 0
(zero), then the drive capacity is 0. Thus when ADSM divides the used space by
total capacity, the divide by zero error occurs.

There is no fix for this problem yet. However, there are a couple of
circumventions:

1) Dismount the drive whose capacity is being reported as 0. This is a simple
fix if it's a music CD, but is probably not practical if it's another type if
drive or file system that is required. In that case, ...

2) Go back to 2.1.0.5 where this problem does not exist.

If you are unsure of which drive is the culprit, there's a fairly easy way to
figure it out. Perform this procedure:

a) Add these lines to your DSM.OPT file:

     TRACEFILE C:\TRACE.OUT
     TRACEFLAGS SERVICE

b) Run DSMC.EXE and recreate the problem. It'll most likely fail immediately.

c) Quit out of the client (if the divide by zero error doesn't already do that
for you!).

d) View the trace file, and go right to the bottom. The last lines should look
something like this:

06/06/1997 10:29:36.0044 : ..\SRC\NTFILEIO.C(2007): fioStatFS(I:\): Entry.
06/06/1997 10:29:36.0054 : ..\SRC\NTFILEIO.C(2095): fsCapacity.lo = 0,
fsCapacity.hi = 0
06/06/1997 10:29:36.0054 : ..\SRC\NTFILEIO.C(2102): fsGUICapacity =     0.50
06/06/1997 10:29:36.0054 : ..\SRC\NTFILEIO.C(2113): fsOccupancy.lo =
-100532224, fsOccupancy.hi = -1
The key things to look for are:
The key things to look for are:

* The drive letter reported In the "fioStatFS" line. In this sample, it's the
I: drive.

* The line with "fsCapacity.lo" and "fsCapacity.hi". These will both show a
value of 0.

This indicates that the I: drive is the one whose total allocation units are
being reported as 0.

Don't forget to remove the trace options from DSM.OPT after doing this.

I understand that this is not a solution, but hopefully this will explain why
this is occurring, and help identify the drive that ADSM
is choking on (if you are not sure of the drive).

Andy Raibeck
ADSM Level 2 Support