FRANK'S FALLACIES, FACTS, AND FICTION
Hello again. I have discovered that it is therapeutic to write
articles for the LANET news so this my fifth attempt at
cranking out an article. These articles have been beneficial
to me because I have stopped answering when I talk to myself
about the mysteries of Netware, DOS, and Windows. I hope you
find this material interesting.
I can be reached via:
1) e-mail at: firstname.lastname@example.org
2) fax at: 310-332-1358
3) messaging via the LANET BBS
(when they get it running again--more on that later.)
4) voice mail at: 213-600-1235
5) "snail" mail at: P.O. Box 2548, El Segundo, CA 90245.
I will incorporate any messages, that I receive, into these
columns, without disclosing the names, clients, or employers
of those who correspond with me, unless I am given explicit
permission to do so.
Various gossip columnists have also cast skepticism and doubt
on Microsoft's 8 megs minimum RAM spec for Chicago. My best
guess is that is will be slower than molasses on a cold day
on 8 megs of RAM and usable at 16 megs of RAM. The latest
scuttlebutt regarding Chicago will ship on time in August with
a zillion problems and unknown glitches but that of these
problems many will be rectified in the 1.1 version which
already exists and will ship 2 to 3 months later. Since the
tolerance for and existence of problems with operating systems
depends on a complex interaction between specific
hardware/software configurations and end-user
attitudes/tolerance, I, for one, at this time, do not wish to
go out on a limb to recommend the upcoming 1.0 version of
Chicago to anyone. However, I remain fascinated by the amount of
income-generating work that the advent of Chicago will generate
for me and others who make a living by supporting this stuff.
We will make honest money, performing upgrades, fixes, and
patches to hardware and software--at both the server and client
level. And, yes, those are dollar signs that you see in my eyes.
I pursued further the rumor that a great deal is available for
LANET members from Novell and discovered the following: There is
a "NUI Benefits Package" that any member of LANET can order for
$49.95. It includes the following:
1) 2-user version of NETWARE 4.1 on CD-ROM
2) 3-user version of GROUPWISE on CD-ROM
3) NSE Pro on CD-ROM
4) 2-user version of "PERSONAL NETWARE" on CD-ROM
5) 3-month trial subscription to APPLICATION NOTES
6) INFOCENTRAL personal information manager on CD-ROM
7) ENVOY portable document publisher and viewer on CD-ROM
8) DOOM shareware network game on CD-ROM
9) CNE CLARKE TEST demo on CD-ROM
10) NUI T-SHIRT size XL only on CD-ROM
Call the following faxback numbers if you are interested:
1-801-429-7177, select option 4, press 1, then enter 700.
Sounds like a super deal. I will order one during the upcoming
I get a good laugh whenever I am installing a input/out card
for a ISA-bus, IBM-compatible PC and the manufacturer of the
card states in their manual that if no interrupts are
available, you should pick a non-standard one for the COM or
LPT port. It is usually as good a piece of fiction as any. Way
back when in the early 80's, when IBM invented the first PC's,
they specified various default IRQ interrupts for the COM and
LPT ports. All bios makers support these default values and
all is well when one uses these values. Now, try to install a
I/O card or a card with I/O ports and try setting it for
nonstandard interrupt settings and you will encounter the most
vendor-specific mess in the computer world: different bios
vendors support different non-standard interrupt mappings for
different COM and LPT ports and these allowed configurations
often differ between different bios versions within the bios'
provided by the same bios maker. I will give more examples and
more practical advice on this matter in next month's article.
Fortunately, a new technology called "Plug and Play" should
solve this mess in upcoming years. For now, it's "plug and
In previous month's I have reported that VLMs are more grief
than the panacea that Novell would like us view them as.
This month, there is more for me to discuss regarding the
on-going epic saga of my trials and tribulations with VMS's:
After experimenting more with VLMs, I finally convinced the
Netware 3.12 client version of VLMs to load successfully onto
an XT/8088 clone. This humble XT only has the traditional
640k of RAM. And this lowly XT is plenty more bloated RAM-wise
when I load the default set of Netware 3.12 VLMs than when I
load the old 3.11 NETX requester/shell--but at least it is
successfully connecting to the associated Netware 3.12
server. This same XT continues to fail to load VLM-based
"Personal Netware". What I have determined is that the
"VLM.EXE" file that is provided as the client piece of Netware
3.12 is not the same as the "VLM.EXE" that is provided with
"Personal Netware". Woe be unto she who gets the two mixed up.
If you substitute one of the "VLM.EXE" 's for the other, it will
be error message and lockup city when you try to connect with a
server or peer workstation acting as a server. But I will not be
taking any of Novell's 4.X classes for a while, so I will not get
the "VLM's are great" brainwashing that they provide--for a while
yet. You will know that that I have been "born again" when I
start singing the praises of VLMs in these articles.
I greatly enjoyed reading Jerry Parsi's article in the last
issue. His comments reminded me of the fact that whenever I
deal with the various vendors of on-site support services for
LAN's, I am reminded of the joke/lament about the guy who dies
and is shown 2 doors by Saint Peter: in one, people are relaxing
in bliss. After this guy picks that door, he gets thrown into
it and finds himself in a burning inferno. He then asks Saint
Peter, "what about the nice place that you showed me" and St.
Peter says "that was just the demo". Sales/marketing personnel
for on-site support services have about a good a credibility to
me as most used car salesman. What you hear about never seems to
be what you get. It is up to the customer/client to keep actual
statistics on actual time to repair in order to have some hard
statistics at contract renewal time in order to counter the b.s.
that is generated by hungry marketing folks--caveat emptor.
The second thought that comes to mind, after reading Jerry's
article: Is that large companies tend to "feudalize".
Employees and their management tend to build artificial walls
around their "empires". These walls are meant to protect the
interchange of expertise, funding, and personnel between other
similar "empires". Those within these petty fiefdoms put in
herculean efforts to keep those of "outside" "empires" from
accessing computer systems, paper documents, and from using
the expertise of employees within the "protectorate". In
many large companies, the various parts of a LAN/WAN
environment can end up "belonging" to various of these
"empires": the hubs and routers might belong to a "network"
organization; the servers might be the territory of a "server
administration" department, the network cabling might "belong"
to a "telecom" organization; and, finally, the workstation
client PC's and Macs might be the territory of a "end-user
support" group. In some cases, these various functions might
belong to various cliques within the same actual department.
The end result is that end-users and network administrators
a lot of grief if these various "duchys" do not coordinate
their activities with one another. Let me know if that happens
at the company where you work.
Last month, I mentioned that the introduction of a computer
in the home can cause consternation for one's spouse or
significant other (SO). Last week, one of the individuals
that corresponds via e-mail with me mentioned that after some
tactful effort on his part, his SO is finally showing
a small amount of interest in his IBM-compatible PC: the little
lady has developed an interest in the DOS-based pharmaceutical
drug reaction and interactions database that he . This fellow
noted that sometimes his SO asks him to fire up his PC so that
they can look up information on various drugs. He noted that
depending on her mood, she can revert back to "computer widow"
-type complaining at times, so he is not totally in the clear
to use his computer at will however. But this a significant
amount of progress--if anyone else makes any progress, you will
hear about it here, with the usual cloak of anonymity for my
According to page 12 of the April 10-May 7 issue of Computer
Currents, "Bugnet" is a "..journal of computer bugs, glitches,
incompatibilities...and their fixes," [for information--F.C.]
send e-mail to BugNetMag@aol.com, or call 360/988-2801. Annual
individual subscriptions are $25, corporate subscriptions are
$50. Mention "Computer Currents" when subscribing and get a
free copy of either "BugNet" 's special report on Peachtree
Accounting for Windows or WordPerfect 6.x for Windows". This
publication appears to be worth checking out--I will do so.
Incidentally, Computer Currents is a fine publication. It is
available for free at many computer superstores.
AST is a fine local manufacturer of IBM-compatible computers.
However, some of their earlier 486's have caused me more than
a modicum of grief:
AST "Premium 486'S" AND "Power Premium 486'S" have BIOS' that
are OEM'ed by Phoenix, the bios company. These former top of
the line PC/server computers have 2 BIOS configuration setups:
1) One that you get into by hitting the CONTROL+ALT+ESC keys
during the start of the power-up bootup sequence
2) One that you get into by booting up into an "EISA
CONFIGURATION DISK 1 OF 2" that comes with the computer.
The two configuration functions are for different sets of CMOS
parameters. The first one is meant for the end-user and the
second one is meant for the system admin/PC support person.
Whenever there is some sort of a CMOS configuration problem on
the PC's of these two lines of PC's, they tend to erroneously
force the user into the "1)" BIOS configuration by means of an
error message that states that
the end user is to:
"HIT F1 TO CONTINUE OR CONTROL-ALT-ESC TO RUN SETUP".
The typical end-user that runs this "1)" configuration then
hollers for PC support/assistance. The PC support/assistance
person then has to run the "2)" configuration in order to
resolve the problem. Having spent the last 6 years working on
AST PC's, I am used to these misleading error messages.
What I was not prepared for in the middle of April was the
following sequence of sleep-robbing events: After completing
a routine network card and cable card installation for an AST
Premium 486, I noticed that it produced the above-mentioned
error message whenever it was booted. The "1)" CMOS
configuration procedure failed to clear the problem, as usual.
We located the "config. disk" and booted the PC with it. After
running the "Configure Computer" selection, we re-booted the PC
and noted that the original error message was gone. Now, we got
another error message: "No system on disk", implying that
there was a problem with the hard disk. I then located a floppy
disk with "system" on it and successfully booted the PC with it.
At this point I noted that there was no sign of a hard drive
whatsoever. Also at this point the end-user of the PC made the
usual and expected profound comment about how the drive held 2
months of his life's work and he did not have a backup for those
files anywhere since "hard drives were too reliable for one to
waste time on backing up files to media". I would have said
something equally "profound"--however the exercise of my right
to freedom of speech would have caused a reduction on my income
for the year. Lucky me. Even though the activity light on the
ST-2383E ESDI-type hard drive was blinking at times during the
bootup sequence, it was totally inoperative--C: did not exist, as
far as the operating system was concerned. To make a long story
short: after 13 hours of the trial, error, cuss, pray, and
stay-up-all night routine, I restored most of the hard drive.
Here is a chronological sequence of what I did:
1) Note original settings in CMOS for the parameters of the
2) Look up Seagate's hardware settings for the parameters of
the hard drive.
3) Noted that the settings found in 1) and 2) were different.
Concluded that the Western Digital hard drive controller was
doing some sort of translation.
4) Looked up the manufacturer's documentation for the hard
drive controller. Noticed that the standard translation that
this controller was not the same as the settings in the CMOS.
5) Located records of maintenance activities in this PC. Noted
that the hard drive was low-level formatted with Ontrack's
"Disk Manager" 4 years ago. Concluded that the original
settings in the CMOS were probably correct because disk
drives that have been formatted by Disk Manager often have
parameters which are different from both the ones found in
1) and 2).
6) Used a floppy disk to run MS-DOS 6.22 Scandisk.
7) Used a floppy disk to run PC Tools 8.0 Diskfix.
8) Used a floppy disk to run Norton Utilities 7.0 Norton Disk
9) Repeated steps 6), 7) and 9) 16 times.
While running Norton Disk Doctor for the seventeenth time, the
planets, the sun, and the moon were in their correct alignment
with my psychic powers and the hard drive came to life. It's
partition table now shows permanent unrepairable damage so that
this hard drive will not boot, but the user can now boot his PC
with a floppy disk that has "system" and get to all his files
and applications. Of course, this user has not gotten around to
backing up any of his data files to media--since hard drives are
so reliable and he can pay people like me to spend the night
with his computer, whenever there is a problem.
Speaking of non-existent backup's for PC's, the backup programs
that come the latest versions of MS-DOS--6.20 and 6.22--continue
to be the most miserable backup programs on the planet. MS-DOS
3.3's backup program was just plain unreliable--whenever one
tried to restore from backup diskettes, one only had about a 40
percent chance at succeeding to restore files. MS-DOS 4.0's backup
was equally atrocious. MS-DOS 5.0's was slightly better. Finally
the backup programs that come with MS-DOS 6.0, 6.2, and 6.22 are
miserable excuses for backup programs. All are slow, compared to
their competition. As mentioned in a previous article, the best
backup program that I have ever used is Norton Backup for Windows--
in my tests, it is 2 to 3 times faster than any of the backup
programs that come with the 3 latest versions of MS-DOS. Also, for
MS-DOS 6.0's backup program, I have found that it has problems
retrieving the backup directory information from backup diskettes.
This can cause a bit of a panic when endusers need to restore
files from a backup disk. Here is a workaround that I have
1) From a pure, non-Windows DOS prompt,
Run a DIR command on the final backup disk.
2) Start the MS-DOS 5.0 backup by typing in:
3) Select "restore", "catalog", "retrieve", etc.
I do not know why the above procedure works when just jumping into
"retrieve" fails to read the "backup directory" from the backup
disk. But this procedure has "saved" more than one end-user of mine.
That was a hard disk failure. But as most of you know, network
equipment can also fail. A few days later, I arrived at a
jobsite and noticed that all of the employees of this small
company were standing around idle. The network administrator
stated that no one could log in to their little 20 node Netware
2.11 network. Whenever the login command was attempted from a
workstation PC, the PC's would hang and require a soft reboot.
The error light at the Synoptics 3030 hub was solid for the leg
of the 10Base-T hub that went to the server. After disconnecting
the BNC connector from the network card at the server, the
problem at the workstations remained. It was time to look for a
transceiver: if there is a thinnet/BNC connection at the server
and a 10Base-T hub in the wiring closet, there has to be a
transceiver that converts 10Base-T to thinnet coax somewhere
and it was darn suspect at this point. After locating and
disconnecting it, workstations quit hanging after the execution
of the "login" command. After replacing the Milan transceiver,
the network was back to normal. What had happened was that this
transceiver was flooding the ethernet network with garbage so
that no clients could connect with the server to get to the
login screen. And this little gem was doing it's dirty work all
by itself--it continued to flood the network with garbage packets,
even after I disconnected it from the server that it was
connected before I disconnected it from the network and sent it
the the round file. So beware of failed transceivers on steroids.
While fighting with all these failures last month, it suddenly
dawned on me that a secondary reason for having a network in
the home environment is to reduce the risk of losing data to
hard disk crashes: Last month, I mentioned that the primary
reasons for installing a "home area network", is for the sharing
of CD-ROM drives. I then gave the secondary reason as printer
sharing. Having backup copies of data files is now the obvious
third reason. As one's household becomes increasingly dependent
on desktop computers, one is increasing exposed to the risk of
hard drive failure. For example, at my home, all of my personal
financial records, medical records, Novell education notes,
college course notes, personal correspondence, etc. now reside
on a couple of hard disks and I am the beneficiary of about one
hard disk crash every year. This additional benefit of having a
home network is only workable if the enduser reliably keeps
current copies of important files on both the local workstation
and on a separate PC that is acting as a server via a mapped
drive for the end-user's "client" PC. The reason that having a
home network is a better backup solution that archiving data
files to floppy disks is that saving files on a mapped drive is
zillions of times faster than saving files to floppies. Hence, it
is more likely that end-users in the home will back up, when a
mapped server-based drive is available than when a stacks of
floppies are provided for archiving files. For years, I spend
up to half an hour a day backing up files on my home PC to
floppies but it was a slow process and how many people are willing
to do that? In order to save even more time, I now write batch
files which automatically archive my data files to my mapped
server-based drive when I exit key applications. For example, I
store my latest draft of the articles that I write for the
LANET News in a file called LANEWS.TXT In order to edit or view
this file, I run a batch file called LANEWS.BAT The last line in
COPY C:\LANEWS\LANEWS.TXT W:\LANEWS\LANEWS.TXT
This line backs up my latest version of LANEWS.TXT to another
PC is running Netware Lite and acting as a "server" when I
exit out of editing LANEWS.TXT. That way, I do not have to
remember to manually back up the latest version of this
important file to a remote Netware Lite drive by manually
executing the above command at the DOS prompt. The end result
is that, with a home network, I do not have to manually
archive LANEWS.TXT to a floppy--all the work of keeping 2 copies
of the most recent version of this file is done
automatically for me.
In the current month, I continued to experiment with Paradox
3.5 and 4.0 in the Netware Lite 1.1 environment. As stated
previously, to make these versions of Paradox see Netware
Lite "servers", one must fire up Paradox as follows:
I can then open and save tables and reports on any mapped remote
drives that reside on peer PC's acting as servers. However, any
reports that I try to run tend to cause a error message that
jumps me back to the DOS prompt. The simple patch, for now, is to
use the report functions by fooling Paradox into thinking that it
is not on a network. To do so, one exits back out of Paradox and
restarts it from the DOS prompt as follows:
I will keep experimenting with Paradox. If anyone has any ideas,
please let me know.
I missed the April meeting because I needed to study for both my
CNA exam and my Advanced 3.1X class. During that week, I passed
the Drake test for Netware 3.1X Administration so whenever the
folks at Novell get around to sending me the certificate, I
will become a official "CNA". My impossible dream is that, some
day, I will be able to keep in touch with LANET members through
the messaging capabilities of LANET BBS, which would be especially
handy when I miss meetings. However, the reality the situation is
that LANET BBS has not been functional for the past 4 weeks--
whenever I try to access it, it's phone line just rings and rings.
I hope that we did not forget to paid the phone bill for this line.
In the meantime, please feel free to contact me using any of the
other methods that I have listed above.
Finally, here is a plug in support of our hardworking,
stressed-out editor: Many fine folks will join an organization
just to get a good newsletter on a subject. In fact, many people
join organizations and pay annual dues just to get copies of
newsletters mailed to them. So, be sure to contribute articles,
letters, and comments to this publication. It helps all of us.
See you next month.
(The previous diatribe is solely the opinion of the author. It
is provided for your amusement and neither LANET, SCNUI, NUI,
NOVELL, Microsoft, or the author's unsuspecting employers and
clients, nor anyone else on the planet can vouch for the
validity of what was stated.)
Back to Frank Chao's