Lewis' Blog Tales from the trenches of information technology


OS/2 NetWare Requester FAQ

The following is based on an oloder NetWare TID, which may or may not still be available. It is provided here as a service to the OS/2 and NetWare communities at large. My version was previously hosted in the Rosenthal & Rosenthal knowledgebase, but as that is currently down for a rebuild, and as I have an upcoming eComStation-to-NetWare consultation, I thought I might put this up here.


Unloading an unloadable NLM

One of the frustrating things about NetWare has always been its distinct lack of a decent process killer. Part of this was perhaps over-confidence on the part of Drew Major (and others), thinking that we would never need a process killer because there would be no such thing as a runaway process on NetWare. Another (good) reason might be that killing a process can sometimes be as risky as letting it run, even if it runs until the next server restart.

With NetWare 6, we got a fairly useful bash implementation, along with some standard utilities (grep, egrep, fgrep, cat, etc.). We also happened to get kill and killall. Now, the problem with kill is, of course, that one needs a process id to feed it. Naturally, among the things we lack is a port of ps (don't ask me why!). Trying killall results in a slew of public symbol errors (at least for me). So, what to do?


Novell’s reponse to my request for NetWare 7

This should really fall under the "I need a laugh" department.

In August of 2009, I sent the following enhancement request to Novell, via their enhancement portal:

Filed under: NetWare, News Continue reading

NLM Memory Tuning

Physician, heal thyself...

One of my NetWare servers has been suffering of late with some runaway memory consumption (I'll leave it for another post to discuss the difference between excessive memory consumption and memory leakage, but suffice it to say, that these are non synonymous conditions). Logging in tonight to check the progress on some backups, I was greeted with:

SERVER-5.70-0 [nmID=2000A]
Short term memory allocator is out of memory.
10 attempts to get more memory failed.
request size in bytes 65536 from Module MYSQLD.NLM

I've not seen MYSQLD run short of memory before, so I took a closer look (backups were still active). I loaded SEG.NLMto see what was going on. The first thing that hit me was that NWMKDE.NLM was consuming over 700MB of RAM, or approximately 21% of the total installed memory in the machine.

Hmmm... What could be the matter, here? Other than Backup Exec, I have no Btrieve apps running on the server. All of the non-system databases run on MySQL on that box. TID # 7003770 references TID # 3216963 (formerly TID # 10058100), which makes reference to deleting the BTI.LCK file created in SYS:SYSTEM. I looked, and sure enough, BTI.LCK was a 0 length file. I deleted it, unloaded BSPXCOM.NLM, BTCPCOM.NLM, and NWMKDE.NLM, and reloaded all of them (I checked my BTI.CFG, and NWMKDE was configured to use 1MB of RAM for cache). Sure enough, memory consumption returned to normal.

Who knows?


Mass renaming files at the OS/2 command line

An interesting head scratcher to which I have been returning almost monthly for some time is the distinct lack of ability to rename files based upon a mask at the OS/2 command line (in a minute, I'll explain why this is a fairly regular occurrence). Of course, OS/2's cmd.exe is not alone in that regard; DOS' COMMAND.COM, 4DOS, 4OS2, JdeBP's 32-bit CMD, Windows' CMD, and even the *nix shells with which I'm familiar don't naturally lend themselves to this kind of flexibility (okay, I lied: you can do it with Bash, of course; see below).

Why a monthly occurrence?

I don't normally send paper invoices to clients anymore. Not only does it kill more trees than it's worth (and no, I'm not an environmental zealot; we grow new trees every day - I'm just the guy who has to buy the paper and the laser toner), but the postage has over the years become a major factor in this decision. Anyone who has to regularly bill clients for outstanding balances knows from whence I speak; send the same client a dunning notice for six months, and that $150 bill has just been whittled down to $147.36 ($0.44 * 6 = $2.64; $150 - $2.64 = $147.36). This just adds the insult to the injury.