paul@vixie.UUCP (Paul Vixie Esq) (12/19/87)
Well, today's story has a happy ending. I began with a message from the
CTG/Telemedia tech support person, who was "not in today" when I called
back. I then asked to speak to the sales rep, who said that the tech
support person was home sick. He would call me back "soon", she promised.
True enough, he called; I gave him yesterday's complaint list and asked a
few other questions about Bell Tech products (more below), and he promised
to call ISC in Santa Monica and get back to me later in the afternoon (it
was, indeed, already afternoon in Chicago).
At about 4:15PM my time, he finally called back to say that the folks at
ISC had read my article on USENET -- yesterday's -- and had modem'ed their
response to him so he could read saliant details to me via telephone. If
that sounds a bit strange, you have the flavor of it. Anyway, it appears
that the most crippling problem (lack of a "macasgn" binary) was actually
an error in the documentation. The program I needed is called "netup" now,
although it is not mentioned in the manuals at all. Fooey. But it works,
and the "usage" message is quite detailed, and so I'm pleased with it.
Now able to load the client's application, I set about entering VP/ix and
attempting to load the first diskette. No go. The diskette seemed to have
errors on it -- I got several "General Failures" and a few "Not Readys".
Hmmm, I thought. This diskette didn't appear to be bad when I loaded it
in with DOS on this same CPU/diskdrive/diskette last week. Let's try DOS
again.. Yup, DOS still likes that diskette. Let's format a diskette in
this machine's drive, use DOS to copy the "bad" distribution disk to this
new diskette (no copy protection here), and try that. Nope. Let's try
formatting a high-density diskette, etc, no go.
Okay, let's borrow a low-density drive and attach it as drive B:. Ha!
The fd(7) man page says NOTHING about the minor device number bit fields
used for /dev/rdsk/f* files; only f0* files (i.e., only the first floppy)
are supplied in /dev/rdsk, and there appears to be no MAKEDEV script like
Berkeley systems have. Hmmm. Fortunately I ordered the software develop-
ment system, so /usr/include/sys/fd.h should have what I need. Yup, the
device number is the low-order bit. What's that? fd(7) says that four
floppy drives are supported -- how can they do that with one bit? Which
one is right? Is either right? Well, one 'mknod f1d9dt c 1 17' later,
I saw that SOMETHING was sure wrong. DOS could use the drive okay, but
386/ix was just not willing. "error 6", I was told. No such device or
address. Fine.
Okay, so: VP/ix and dossette both say that most of my DOS diskettes of
either density are bad. DOS says they're good. 386/ix will in general
not deal with a 360K drive as B:, although DOS has no trouble. How am I
going to load in my client's software package? (much yelling and griping
ensues). Ah, I'll use DD! Yes! Maybe if I dd(1) the whole diskette into
a pseudo-floppy (a UNIX file that VP/ix can treat as a DOS filesystem), I'll
be able to read the disk! Well, what do you know -- it worked. Okay, so
now I can just switch abck and forth between two virtual terminals: I load
a floppy into a file called "B:" using dd(1) under UNIX, then switch to a
VP/ix session and press RETURN to the "please insert next diskette..."
prompt. 25 floppy disks later, this is done. (I should note that I had
to use B: for the pseudo-floppy because if you configure A: to be one, VP/ix
will try to boot DOS from it, which won't work because DOS isn't there.
Therefore I used B:, except that the software's installation procedure
assumes drive A:, so I had to "assign a=b". They don't call me the King
of Kludge for nothing...)
I kept wondering if my client could ever have figured this out, even if
given all the documentation that I can't get for them yet. I decided: NO.
That's okay, I'm paid by the hour. Sure wish ISC or CTG/Telemedia had TOLD
me that this product was still in BETA-TEST though -- my attitude would have
been much softer all around...
I forgot to say, yesterday, that ^C doesn't work for me. I've set my 'intr'
character to a variety of things, and UNIX just ignores whatever character
I choose. There are modes in stty(1) for ignoring interrupts, enabling or
disabling the generation of SIGINT on BREAK, and lots of other things --
none of them either singly or in combination with their fellows was the
magic thing. I just use ^\, though, and rm all the core files this causes.
Again, I feel sure that my client would NOT have figured this out easily.
^C works fine inside VP/ix, I should add. No signal(2)'s involved there,
I guess.
Okay, now for the good parts:
VT's (virtual terminals) are Very Nice. Once I figured out what the "hot
key" was, I began to use VT's incessently. I especially like being able to
run VP/ix on one VT and a UNIX session on another VT.
Those pseudo-floppies (DOS file systems in UNIX files) are created by VP/ix
at size 0, which I like. Nothing in there until you put it there..
I built a kernel tonight, just for fun. I built the 'std.unix' system, and
as predicted it generated a slightly different kernel than had come with the
'core 1.0.4' system. No problems here, except that usermem went from 825K
to 775K, so now I have to start trimming out the various facilities I don't
expect to need. On a 2MB system, 50K is a noticable drop (just listen to
that actuator arm - best system tuning tool I know of :-)). Building and
installing the kernel, though, was a charming experience. No problems, no
wierdities that needed special treatment, nothing odd at all. kconfig(8)
prints little menus that let you control/direct the process, and you get
a neat little kernel in / with a new name and a link to /unix with the old
kernel renamed to /OLD.unix. The system reboots with messages about what
to do if the system won't boot, etc, etc. Very nice. Here's something I
think I could tell a client to do over the phone --- or maybe do over a
modem myself. NICE.
Some questions:
It looks, from /usr/include/sys/hd.h, that ESDI support for ADAPTEC and
WD-1005-WAH controllers is now included in the hard disk driver. I wonder
if I can just put the 385/ix "boot" disk into a machine with a WD-1005-WAH
and a CDC 94166-182 ESDI 182MB drive, and have the install program see the
drive, know its geometry, do the low-level format, partition it, and finish
the install? (Obviously a floppy controller will be needed as well) The
installation for a WD-1002-WA2 + 44MB generic drive was Very Very Simple,
and I would love to be able to specify a higher-performance mass storage
for future clients.
I promised more about Bell Tech hardware questions, so here it is. I tried
to order an ICC "smart serial card" from Bell Tech today, and they said that
they could not include the driver for the ISC kernel since they had already
shipped the driver to ISC and ISC was supposed to include it. Looking in
/etc/atconf/?/descriptions, I saw mention of the HUB (dumb) card, but
nothing about the ICC. The tech support guy at CTG/Telemedia said that ISC
had told him that the 'asy' driver would work for the ICC, which I think
(and told him) was absolutely unbelievable. The ICC has an on-board 80186
and six ports -- no way is it going to fit into the same space and have the
same semantics as the COM1/COM2 ports of the standard 'asy' driver. He's
going to ask again on Monday and tell me what he finds out. Since Bell Tech
specifically said that a new driver was written for the ICC, the only way
that the 'asy' driver could possibly work with it is if ISC "hid" ICC support
inside 'asy', which is less likely than hiding WD-1005-WAH support inside
'hd', though possible. Just damned unlikely.
The other thing Bell Tech couldn't sell me today was a T-60 tape drive. I
saw an "AT WangTek tape" driver in /etc/atconf/?/descriptions, and I know
that the Bell Tech drive is a WangTek, but I don't know about the controller.
Neither does Bell Tech. They have a special "streaming TAR" program which
is supposedly optimized for their drive+controller, and they seem to think
that they sent a special driver to ISC for inclusion in the kernel. Since
/etc/atconf/?/descriptions explicitly names "Bell Technologies" in the
description of the HUB card, I feel somewhat certain that they would have
specified "Bell Tech" on the WangTek driver if it was really Bell Tech's
driver. Then again, maybe the controller is standard enough to use a
standard driver, and ISC didn't need Bell Tech's driver. I don't know.
This is another one that the CTG/Telemedia techsupportguy was going to ask
about on Monday and get back to me.
Some troubles with the hardware configuration:
ISC suggests 4MB of memory in their advertisements and manuals, and they
are NOT lying. I thought 2MB would be enough for a single user machine,
but it turns out that of 2MB physical memory, only 640K + 1MB = 1684K are
available, and after the kernel starts up you're down to about 800K or so.
Whenever CRON wakes up, you can hear the swapping/paging/whichever. When
switching back&forth between VT's, you hear the swapping/paging/whichever.
Now I just have to wait for the motherboard manufacturer to start producing
2MB memory cards for their non-standard 32-bit memory bus. No gripe here,
I knew about this problem before recommending the machine.
The CPU I sold these people has EGA built onto the board. Even under DOS,
there are problems with it -- Supercalc3 gives me a blank screen whenever
I ask for a pie chart or other graphic widgit. Well, VP/ix always starts
up with a blank screen, and I've learned that running a UNIX command (pwd
is my favorite) will being up a different VT (new font, etc) for the UNIX
command -- which makes the screen come back on -- and the screen stays on
when I go back into VP/ix. I've modified the AUTOEXEC.BAT to run 'pwd',
which is a pain in the butt but at least something I can work around. I
do not suspect VP/ix bugs, since Supercalc3 had trouble with it as well.
Time for a graphics adaptor... for $50, I'll eat the cost of it just to
make sure I never have to explain to the client why his screen went blank.
Winding down... I'm quite a bit less angry today than I was yesterday, as
readers of both articles will be able to tell. I'm not sure if I've ever
FLAMED before yesterday, and I'm not sure I like the way I feel about it.
Since ISC is reading this (which I hadn't considered yesterday), I should
have been quite a bit more polite than I was. ISC, if you're listening,
please accept my apologies.
--
Paul Vixie
{pyramid,sun,hplabs}!ptsfa!vixie!paul
paul%vixie.uucp@uunet.uu.net
415/647-7023