When I got to work this morning, none of my printers would work (serial,
not shared). The following cryptic message was on on of them:

Rebuilding B-tree overflow...
Frame out of Range ; reg= 15 @ ovf.blk:057
O=Logoff

This was printed several times.

I shut down D3, and brought it back up, but user-coldstart just gave me
the following error messages "Cannot start printer n".

I spoke to Joe @ Zumasys, and he suggested checking for free disk space.
This is the result:
[root@localhost root]# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda9 2269000 173392 1980348 9% /
/dev/hda2 101107 9301 86585 10% /boot
none 127472 0 127472 0% /dev/shm
/dev/hda3 2719748 2563940 17652 100% /usr
[root@localhost root]#

I powered down the CPU and rebooted. Everything "seems" fine now, but
I'm concerned.

Do any of you have ideas or suggestions?

I'm running D3 7.4.0.m1 on RedHat 9.0.

Thanks,

Bruce Ackman

bruce ackman wrote:
Take a look at what's eating all of the space in /usr, system says
it's 100% used. Unfortunately I don't think that's related to your D3
errors. Did you check disk space in D3? Use "what wsl" or povf to
see available frames. My guess is your overflow control block might
be corrupted. That could lead to data corruption, or more of these
seemingly unrelated errors occuring randomly later.

We should get concensus from our colleagues here but I think there are
only two real solutions for that:
1) If you have a large contiguous block of overflow, my choice would
be to ask RD or Zumasys to hack the overflow table so that only this
block is left. I haven't done this for years but I know the process
is very simple and fast.
2) Full-restore. Draconian and time consuming.

HTH, Good luck.
T

Tony Gravagno wrote:
screens to PC running Accuterm and connecting via SSH. Since there
doesn't seem to be "nailed SSH" like there is with telnet, each users
linux login runs a script that logs them into a particular d3 port, and
exits linux when they exit d3. If they do not "exit" d3, they do not
release the port they've logged in on. Then I have to kill the pib from
Linux and reset-user on the D3 side. According to epick, this does not
release their workspace back into overflow. I suspect this is the
problem. Is there a way to correct this?

thanks,

Bruce Ackman

BTW, I deleted out of /usr a bunch of stuff I never use on this system
(LaTex, gnome, X-windows) and freed up about 17% of /usr.

bruce ackman wrote:
There are two discussions going on here: You're describing the
possible cause of the problem, but that's not related to fixing the
problem that now exists which is what I addressed.

If overflow is corrupted you need to fix that before it messes
something else up.

Now as to the cause of what corrupted the overflow... The history you
describe should not result in the overflow corruption that you're
experiencing. However, we've all seen stuff like this happen before
when it shouldn't. The first thing to do is to ensure that overflow
is no longer corrupted. The next thing is to investigate how you have
DCD set, whether an option in your "d3" command, and/or the dcd-on and
trap-dcd commands (Google for info and/or see the D3 Reference doc).

You should not have to hammer processes in a current D3 release like
we used to in the past. If you do, contact your VAR and/or RD
Support. While it's not perfect, the logoff command escalates through
various levels of killing and resetting whatever is required to get
user workspace back to a usable state. Killing PIDs is brutal,
shouldn't be required, and should be avoided. There's no doubt that
you can lose frames by killing the process under D3 because D3 isn't
given the chance to release those frames, but based on development
made in the 7.x releases, the system-wide overflow table should not be
corrupted as a result. I'm not saying people should never kill pids,
I'm saying if you find a need to kill a pid then this issue in itself
should be reported to RD so that they can fix it. Otherwise by
resorting to draconian port recovery methods you're just asking for
trouble. Mark is probably much more up on this than I am.

EPick, if you're looking at the big red book, was obsolete as of AP
5.2.x. Since then there has been the Advanced Pick Reference Manual
for 6.x, and the D3 Reference Manual which can be downloaded from the
RD website. D3Ref is notoriously out of date and incorrect but D3Ref
for an upcoming 7.x release has been vastly upgraded and should be
much better, depending on the QA put into it.

T

My intent is not to get off-topic, nor to presume that you do not have
specific reasons for using nailed telnet.

However, I have solved a few legacy "port specific" application problems by
assigning a fixed IP addresses to each client PC where applicable (otherwise
we use DHCP). Then by tweaking the code to use the IP address instead of the
port number, we still have a method to determine the user location without
using nailed telnet.

We also use unique user logon IDs, so at times our preference settings are
based on "who" instead of "where" the user is located.