brown@vidiot.UUCP (Vidiot) (01/09/90)
OK, I received my new UNIX on Friday. I spent all weekend getting it going.
Obviously I got it going, otherwise I wouldn't entering this with the new
system.
Unfortunately, there are a couple of problems.
The major problem is that NH tech support won't talk to an individual like me.
I think that sucks. I did get him to answer a lp problem. Personal opinion
here, but the lp and lpadmin pages talk about the nobanner and width options.
I find out that isn't supported and I had to manually edit the lp interfaces
script. Bummer. Sounds just like UNIX to me :-)
OK, now for the real problems.
For some stupid reason I can't get access to com1 (tty00). If I do a
cu -ltty00
I get:
connect failed: CAN'T ACCESS DEVICE
Before you say that the hardware is at fault, I have switched the hardware
around and it doesn't make any difference. It actually did work a couple
of times, but hasn't sense. Yes, I have built new kernels. Is this the bug
that one of the updates fixes? Not only does cu not work, but the line can't
be used for anything else either, especially vpix. (Boy, I was swearing at
that for awhile also.)
BTW, the NH salesperson that talked to me was real helpful in taking my name
and address so that I can be sent all of the update diskettes, new XWS
diskette #5 (mine was bad) and a new Programmer's Reference manual (mine
has messed up pages [bad printer quality control]). Now to find out how
long it will take to get here.
As far as the tbl program problem is concerned, I just loaded up the old
MicroPort tbl program. I can't wait until it arrives.
All of the programs that I compiled under MicroPort work directly here.
I too don't like the compiler complaining about text after #endif lines.
I'm thinking about loading up the Green Hills compiler, as it didn't complain.
The other minor problem: where and how are the filesystem partitions labeled?
The partitions were automatically labeled when they were created, but I have
moved the mounting sequence around, since another hard disk was added. I would
like to relabel them so the mounting program doesn't complain about cross-
mounting.
I haven't had a chance to dig into this problem yet, but what is the deal
with the modems that are attached to a com port having to have the carrier
detect on before they can be addressed. Is there something that needs to be
changed so that isn't necessary. I want to get the modem set up (com2) so
that it will be dial-in as well as dial-out. I haven't had a chance to look
at the portion of the manuals talking about bidirectional uucp. Any help
to manual pages or tips for various file settings would be appreciated.
I plan on having anonymous uucp access to this system so that the stuff I
produce can be obtained without having to mail it out.
Thanks for your help in advance. I'm not new to Unix, but just to ISC's
idea of doing some things.
--
harvard\ att!nicmad\ cs.wisc.edu!astroatc!vidiot!brown
Vidiot ucbvax!uwvax..........!astroatc!vidiot!brown
rutgers/ decvax!nicmad/ INTERNET:<@cs.wisc.edu,@astroatc:brown@vidiot>cpcahil@virtech.uucp (Conor P. Cahill) (01/09/90)
In article <3@vidiot.UUCP>, brown@vidiot.UUCP (Vidiot) writes: > The major problem is that NH tech support won't talk to an individual like me. > I think that sucks. I did get him to answer a lp problem. Personal opinion > here, but the lp and lpadmin pages talk about the nobanner and width options. > I find out that isn't supported and I had to manually edit the lp interfaces > script. Bummer. Sounds just like UNIX to me :-) I believe the only thing I had to do to turn off banners was to place BANNERS=0 into /etc/default/lpd. > For some stupid reason I can't get access to com1 (tty00). If I do a > > cu -ltty00 > > I get: > > connect failed: CAN'T ACCESS DEVICE To get more information about why this is failing, try: cu -d -ltty00 This turns on debugging and will probably explain the problem. The first thing I would check is the mode of /dev/tty00. Then I would check to make sure that the major device number for tty00 is the correct number. > All of the programs that I compiled under MicroPort work directly here. > I too don't like the compiler complaining about text after #endif lines. > I'm thinking about loading up the Green Hills compiler, as it didn't complain. The compiler is complaining because it text after an #else/#endif is un-supported and may cause future compilers to fail to compile your program. Another reason is the you may have accidently placed code to the right of a #endif As opposed to changing the compiler I would change the text to a comment. like: #endif /* #_DEF_LABEL */ > The other minor problem: where and how are the filesystem partitions labeled? Use the labelit program to label a file syste. This must be done when the file system is not mounted. You should also modify the /etc/partitions and /etc/fstab files to agree with the new labels. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
platt@ndla.UUCP (Daniel E. Platt) (01/11/90)
In article <3@vidiot.UUCP>, brown@vidiot.UUCP (Vidiot) writes: ... > OK, now for the real problems. > > For some stupid reason I can't get access to com1 (tty00). If I do a > > cu -ltty00 > > I get: > > connect failed: CAN'T ACCESS DEVICE In your /usr/lib/uucp directory, there are several files that describe to the various UUCP utilities what configuration you're dealing with. In your Devices file, you have entries for various ways that you can connect to the tty lines. Example: if you want to call a system via 'cu <system name>' then you need an entry like: ACU tty00 - 2400 hayes is an entry that tells 'cu' and 'uucico' that 'Auto Call Unix' device at 2400 baud uses a 'hayes' dialing sequence. The details of that sequence are defined in your Dialers file. Another example: if you want to make a DIRECT connection to the tty line, you'ld need to issue a command like 'cu -l tty00 -s 2400' to connect to tty00 at 2400 baud. However, you'd need an entry in your Devices file that would look like: Direct tty00 - 2400 direct You'd need one such entry for EACH speed (ie 9600 or 19200 baud) that you intend to use. > As far as the tbl program problem is concerned, I just loaded up the old > MicroPort tbl program. I can't wait until it arrives. You have troff with microport? > > All of the programs that I compiled under MicroPort work directly here. > I too don't like the compiler complaining about text after #endif lines. > I'm thinking about loading up the Green Hills compiler, as it didn't complain. I like Green Hills compilers. There are some things to be aware of. For example, x==y doesn't produce a '1' if x == y; it produces a non-zero. More important, there are libraries that don't work well with Greenhills stuff (on my system, which is ATT). I never got the X11 stuff working right. On the other hand, its FAST. > I haven't had a chance to dig into this problem yet, but what is the deal > with the modems that are attached to a com port having to have the carrier > detect on before they can be addressed. Is there something that needs to be > changed so that isn't necessary... This could be a microport problem, but I doubt it. Some modems echo answer characters to uugetty. If uugetty gets characters before CD, it may flush things and start over. You may need to set the modem flags so that they default to having no echo before answering. You also might consider looking at your /etc/gettydefs file to make sure that before answering, NOECHOx flags are set, and ECHOx flags AFTER answering. This is also a nice file because you can use it to modify your remote login banner. The modem defaults are sometimes settable with DIP switches. If you're using a Telebit Trailblazer, you can set them up in ROM with no problem. 'cu' direct allows you to do some set-up experimentation if you have the Devices file set up. I'd also recommend getting a 'breakout box' to help experiment with getting things set up (you can 'fake' a CD always on for example 'till you get the rest of it right). >...I want to get the modem set up (com2) so > that it will be dial-in as well as dial-out. I haven't had a chance to look > at the portion of the manuals talking about bidirectional uucp. Any help > to manual pages or tips for various file settings would be appreciated. I don't recall this being a huge problem (it was a little tricky with the Trailblazer). You could tell the Trailblazer to ignore output from uugetty but then you couldn't talk to the Trailblazer at all. At the same time, if uugetty echoed back the Trailblazer's messages, it hung up. The way around this connundrum was to turn of pre-answer echoes in the /etc/gettydefs file. Then the modem could both answer and dial out with no problems. To have dial-outs, you need to define what systems you are dialing. This is done in the /etc/lib/uucp/Systems file. This essentially contains entries: <system name> <legal dial days/hours> <pseudo-device--'ACU'> <speed> \ <number> <auto login sequence> The ACU (like the description in Devices above) associates some system configuration info with a pseudo device name (ACU, ACU1, ACU2, &c). The auto login sequence looks like prompt - response. If you want to set up auto-dialing for Polled mail pickup, you need to set up the /usr/lib/uucp/Poll file to tell UUCP what hours to poll the other systems. You also want to set up the Crontabs file from account 'uucp' to run polled pickup. I can't think of anything else that you need to do. I hope the above descriptions of what the files do helps you follow the documentation better. > > I plan on having anonymous uucp access to this system so that the stuff I > produce can be obtained without having to mail it out. > Dan