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:  fchao@cerfnet.com
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.


FICTION ??

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-800-228-4684 or
1-801-429-7177, select option 4, press 1, then enter 700.

Sounds like a super deal. I will order one during the upcoming
month.

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 
pray".

FALLACIES ??

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.

FACTS ??

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
correspondents.

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 

and 

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 
   hard drive.
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 
   Doctor.

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 
discovered:

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:
   MSBACKUP  
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 
LANEWS.BAT is:

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:

PARADOX -SHARE  

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:

PARADOX 

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.)