RAH@IBM.COM ("Russell A. Heise") (07/12/90)
geoff@edm.uucp (Geoff Coleman) writes: > ... > 1) bi-directional line support > I have tried a number of times to set a getty as being bi-directional > but have had no luck in being able to call out on this line. It would appear > that getty locks the line as soon as init fires and that cu (or uucico) can > then not gain access to the line. > ... No, this does not appear to be fixed in later releases. If you enable the line with pdelay or pshare, you can use cu or uucico to dial out. However, if the line is not active and getty sees a call-in, getty locks the line and then leaves the lock file after the call-in user has logged out. You may want to contact your local IBM representative and have him/her report the problem as a Software Defect. > 2) cron > We are having a couple of problems with cron. THe first is that > it doesn't seem to want to allow other people access to cron. > ... > The other problem that we are having is that cron's idea of time > is relative to EST or some other Time Zone not the MST that the machine is > running under. The later releases do not show this behavior: with proper cron.allow, all users can use cron. The time is also in sync with the machine time. > 3) parallel device > How do you configure the printer to accept a line more than 80 > characters wide. I assume that this is done through smit but in our load > the change characteristics command for smit does not work. Yes, the later releases of smit properly change the "Number of COLUMNS per page" value for the printer. A wide printer would need some value > 80. Russ Heise, AIX Technical Support, IBM rah@ibm.com
robin@sabre.austin.ibm.com (Robin D. Wilson/1000000) (07/13/90)
In article <071290.095832.heise1@ibm.com> RAH@IBM.COM ("Russell A. Heise") writes: < < geoff@edm.uucp (Geoff Coleman) writes: < > 1) bi-directional line support < > I have tried a number of times to set a getty as being bi-directional < > but have had no luck in being able to call out on this line. It would appear < > that getty locks the line as soon as init fires and that cu (or uucico) can < > then not gain access to the line. < > ... < No, this does not appear to be fixed in later releases. If you enable the < line with pdelay or pshare, you can use cu or uucico to dial out. However, if < the line is not active and getty sees a call-in, getty locks the line and < then leaves the lock file after the call-in user has logged out. You may < want to contact your local IBM representative and have him/her report the < problem as a Software Defect. I missed the first post (with the original question), but under AIX v.2.2.1 for the RT/PC this problem is fixed. It requires OPSYS update level 1764 (or 2706) and VRM level 1710. I personnaly have my machine setup with a Telebit trailblazer that I use for test just such problems, nd I do not have a problem with being locked out of the port. (There was a relaese for the RT that had "cu" setting the tty permissions to 644 which made the port unwriteable by the next user -- this has also been fixed, but I am not sure if the update is currently avaiable with this fix.) If this is a RS/6000 or PS/2 AIX problem ignore what I said.... +-----------------------------------------------------------------------------+ |The views expressed herein, are the sole responsibility of the typist at hand| +-----------------------------------------------------------------------------+ |UUCP: cs.utexas.edu!ibmchs!auschs!sabre.austin.ibm.com!robin | |USNail: 701 Canyon Bend Dr. | | Pflugerville, TX 78660 | | Home: (512)251-6889 Work: (512)823-4526 | +-----------------------------------------------------------------------------+