Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!mcf!teemc!fmeed1!wehr From: wehr@fmeed1.UUCP (Bruce Wehr) Newsgroups: comp.sys.hp Subject: Re: More HP-UX 6.5 puzzlements (long) Message-ID: <3369@fmeed1.UUCP> Date: 19 May 89 19:42:43 GMT References: <3344@fmeed1.UUCP> <5570185@hpfcdc.HP.COM> Organization: Ford Electronics Division, Dearborn MI Lines: 66 In article <5570185@hpfcdc.HP.COM>, perry@hpfcdc.HP.COM (Perry Scott) writes: > >Unfortunately, this is the way I was already set up. Something changed > > If minor number 0xSC0001 (simple mode callout) is used and HUPCL is on, This is the way I'm set up for my cul* files. My tty* files are simple mode call-in (0xSC0000). > >I don't have time to read the documentation cover to cover before I > > This sounds like a basic problem in documentation for a complex system. > The system is so big that nobody can know everything about anything. When I set the system up, I read all the pertinent documentation (termio(7), modem(7), etc...). A little obscure, but things worked as expected. I knew the material *well* then. That was over 2 years ago. > >*PUT* *IT* *IN* *THE* *UPDATE* *NOTES* > > Is this reasonable ? [...] > [...] If you are really saying you want to see > the impacts of several hundred defect fixes to the system, along with a > writeup of all the new features, I'll accept that. > [...] > If you are using undocumented features, then I'm afraid it _is_ your > problem. I guess I'm saying that I'd like to be informed of anything that causes externally visible changes to the behavior of the system, whether or not the behavior was previously documented. > If you "or" 0x08 into the minor number, a form of hardware handshake will > be enabled. Thanks, I didn't know that. Does it also work the other way (the S300 dropping/raising RTS to pace characters coming into it)? > [...] I'm just trying to help you get your job done, engineer-to- > engineer. It may not sound like it, but I *really* do appreciate you (and everybody else that has) taking the time to respond. Thanks. I now have more clues to the behavior giving me problems: It seems that DTR is not dropped at logout *only* if the user has daemons running. Not 'background jobs' as the shell knows them (those launched with a trailing '&'), but programs that fork and the parent exits. We use month(1) here, a calendar-appointment/reminder system. Users can execute monthd(1) in their .profile, which forks and the child stays in the background to issue reminders. At logout, this process (or any leave(1)s, or any other daemons) would be killed and the session disconnected (meaning DTR was dropped). After we upgraded to HP-UX 6.5, these processes persist and DTR is not dropped. Can anyone explain? BTW, the behavior of 'background jobs' (launched with '&') doesn't seem to have changed. After convincing ksh that you *really* want to log out (after its 'You have running jobs' warning), these processes are killed, you are logged out, and your session is disconnected. Again, thanks to everyone who responded. -- Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com) (...!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu) Ford Motor Company - Electronics Division 17000 Rotunda Drive, DPTC Room LN081, Dearborn, Michigan 48121 (313)845-3039