wehr@fmeed1.UUCP (Bruce Wehr) (04/27/89)
We recently installed HP-UX 6.5 here. Two items appeared almost
immediately:
_P_r_o_b_l_e_m_ _1_:
We have some ksh scripts (beginning explicitly with '#!/bin/ksh') that
take advantage of the job syntax '%jobno'. The scripts launch a couple
of jobs in the background, perform the foreground task, and then do a
'kill %1 %2 ...' to terminate the background jobs.
With HP-UX 6.5, the message "kill: %1:No such job" is issued if this is
attempted from a script. This still works fine interactively. Try:
sleep 5 &
kill %1
both interactively and from an explicit #!/bin/ksh script to see what I
mean. I've read the 6.5 update notes, and thought that this might be a
side effect of the new job control, but I can't seem to pinpoint it.
_P_r_o_b_l_e_m_ _2_:
We access our 370 here mainly over a Sytek LAN. These Sytek boxes are
configured to disconnect the current session when it sees DTR drop. DTR
is supposed to be dropped by the system when a user logs out, until the
next getty opens the port. This is no longer happening with HP-UX 6.5.
I see no reference in the update notes about the tty drivers changing.
Many thanks in advance for any pointers regarding either or both of
these problems.
--
Bruce Wehr
(...!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-3039wehr@fmeed1.UUCP (Bruce Wehr) (05/13/89)
In article <1020024@hp-ses.SDE.HP.COM>, tai@hp-ses.SDE.HP.COM (Tai Jin) writes: > |We access our 370 here mainly over a Sytek LAN. These Sytek boxes are > |configured to disconnect the current session when it sees DTR drop. DTR > |is supposed to be dropped by the system when a user logs out, until the > |next getty opens the port. This is no longer happening with HP-UX 6.5. > |I see no reference in the update notes about the tty drivers changing. > > You might try to set HUPCL in the /etc/gettydefs file for that line or do > a "stty hupcl". Unfortunately, this is the way I was already set up. Something changed with Revision 6.5. Does anyone know what? Is anyone out there using DTR control with HP-UX 6.5? If so, can you tell me your set-up (special file minor number, etc...)? This capability is important to me. > |We have some ksh scripts (beginning explicitly with '#!/bin/ksh') that > |take advantage of the job syntax '%jobno'. The scripts launch a couple > |of jobs in the background, perform the foreground task, and then do a > |'kill %1 %2 ...' to terminate the background jobs. > > The shell must be in interactive mode for this to work. That is, you should > have "#!/bin/ksh -i" at the beginning of your script. Altering my script as you suggest does make this feature work. It also litters the output with unnecessary prompt characters. I can't find this requirement documented anywhere. Maybe this feature was never intended to be used in a script. But, it *used* to work in a script. I mean, please, excuse me while I... * FLAME ON * I don't have time to read the documentation cover to cover before I attempt to implement something. So, there are times I just 'try it and see if it works'. If it does, GREAT. If it doesn't, maybe a peek at the documentation will help. If it *does* work, but the documentation says that it isn't *supposed* to work that way, I don't know that. If a change is made to HP-UX to make the *actual* match the *documented*, that's great, *BUT*......... *PUT* *IT* *IN* *THE* *UPDATE* *NOTES* Both of the above mentioned situations (DTR on hang-up, %jobno syntax for ksh) were operating in a fashion that I took advantage of (I won't dispute whether the behavior was *correct* or not). When I upgraded OS's, I changed nothing else (except for a 350 -> 370 upgrade; don't tell me *that's* my problem). The behavior of these items changed, and the system no longer operated in the same fashion. I don't have the time to re-search the documentation, or re-learn the material. I *make* time to read update notes. I saw *NOTHING* in the update notes. * FLAME OFF * I'm not addressing anyone in particular (even though I did pick your article, Tai :-). I just thought that this is the way things should be. I've resolved the %jobno problem by not using that syntax at all. The script remembers the PID (jobx=$!) after starting each background job. It kills them later the same way (kill $job1 $job2). However, the DTR problem still eludes me. And while I'm on the subject of tty drivers, here's one: Is there any way (minor number, etc...) to enable hardware handshaking? I'm getting a Trailblazer soon, and would like to use hardware handshaking. I've read suggestions about using XON/XOFF with the UUCP 'f' protocol, and I'm looking into it. But, hardware handshaking works for the Datacomm card (98628?) under the BASIC Workstation. Can I somehow enable it under HP-UX? Any other comments? Suggestions? Criticisms? Solutions? Problems? Thanks for letting me bend your ear :-) -- 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
perry@hpfcdc.HP.COM (Perry Scott) (05/16/89)
>Unfortunately, this is the way I was already set up. Something changed >with Revision 6.5. Does anyone know what? Is anyone out there using >DTR control with HP-UX 6.5? If so, can you tell me your set-up (special >file minor number, etc...)? This capability is important to me. If minor number 0xSC0001 (simple mode callout) is used and HUPCL is on, then DTR should go down when the device file is closed. That is the documented behavior. Admittedly, the TERMIO man page is a bit obscure, but it's in there. The callout file will raise DTR and wait for CD from the other side to go high. You could wire DTR to CD if the other side doesn't raise CD. Re: * FLAME ON * >I don't have time to read the documentation cover to cover before I >attempt to implement something. So, there are times I just 'try it and >see if it works'. This sounds like a basic problem in documentation for a complex system. The system is so big that nobody can know everything about anything. >If a change is made to HP-UX to >make the *actual* match the *documented*, that's great, *BUT*......... > >*PUT* *IT* *IN* *THE* *UPDATE* *NOTES* Is this reasonable ? There are hundreds of defects repaired in each release. If HP documents all of them, customers would either not read it because the list is too intimidating, or the signal-to-noise ratio would be too low to be useful. 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. >Both of the above mentioned situations (DTR on hang-up, %jobno syntax >for ksh) were operating in a fashion that I took advantage of (I won't >dispute whether the behavior was *correct* or not). When I upgraded >OS's, I changed nothing else (except for a 350 -> 370 upgrade; don't >tell me *that's* my problem). If you are using undocumented features, then I'm afraid it _is_ your problem. If you find a feature that does not work as documented, then that is something you should tell HP about via the normal support channels. If DTR doesn't go down when HUPCL is set, let your SE know. >The behavior of these items changed, and the system no longer operated >in the same fashion. I don't have the time to re-search the >documentation, or re-learn the material. I *make* time to read update >notes. I saw *NOTHING* in the update notes. Again, I think there is a basic problem in the structure of the information presented. There is too much unstructured information to allow a person to quickly find what they need to know. >And while I'm on the subject >of tty drivers, here's one: Is there any way (minor number, etc...) to >enable hardware handshaking? If you "or" 0x08 into the minor number, a form of hardware handshake will be enabled. It isn't documented well because it isn't true hardware handshake, but works for most applications. When this bit is set, then CTS being lowered it has the same effect as receiving XOFF. When CTS is raised, it has the effect of XON. Since XON/XOFF is under control of the s300 driver, it may not stop the data immediately and a few more characters will dribble out - I don't know if the Telebit can handle this. (BTW, this is all s300-only.) The 98628's HWHS isn't used because UN*X likes to think it is in control of the pacing. >Thanks for letting me bend your ear :-) I'll consider it bent. Don't take what I say as official HP support policy. I'm just trying to help you get your job done, engineer-to- engineer. Perry Scott HP Ft. Collins ..{ihnp4,hplabs}!hpfcla!perry-s
wehr@fmeed1.UUCP (Bruce Wehr) (05/20/89)
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
wehr@fmeed1.UUCP (Bruce Wehr) (05/23/89)
In article <3240090@hpfcdc.HP.COM>, rer@hpfcdc.HP.COM (Rob Robason) writes: > I can sympathize with your feelings if your job is not primarily to > develop software, it would be nice if these things were more intuitive. Software development *is* my primary job. System administration is not. > [...] But what you describe > is generally an unsafe software development practice. [...] > There are literally thousands of cases where it is unsafe to rely on > anything other than the documented behavior of calls and commands in > writing applications. The ksh %jobno syntax *was* documented. The fact that it must be an interactive shell was not. Was I wrong to use it in a script? > What I hope is that applications developers will treat software > development as a job to be performed in a professional manner, not as a > hobby to be done in one's spare time. Amen. Unfortunately, system administration is something I must do as a hobby in my spare time. Learning the file system, system calls, etc. well enough to develop robust applications is a full time job. Learning shells, tty drivers, user account management, etc. is a full time job, too. I try my best to do both, but writing applications has priority. In general, I could not agree with your positions more. I just don't think I was taking advantage of 'undocumented features'. Do you? -- 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