vemis@pnet51.orb.mn.org (Jeff Mo) (09/02/89)
Sorry for needing to repost, I don't know how the first half of my previous posting got lost. Here is the entire posting again. In release 2.2, SCO had their own program called ungetty which would suspend a getty while doing a dial-out (like the generic uugetty). In release 2.3, SCO still has the program ungetty, but is has been stubbed. It will always return a 0, and does nothing. (My application written under 2.2 called ungetty and worked, and failed to call out correctly under 2.3 when calling the non-working ungetty.) A call to SCO told me that the 2.3 HDB does the same type of getty suspend when the correct device lock file is placed in the /usr/spool/uucp directory. This is detailed in the May/June 1989 SCO Discover bulletin starting on page 35. The lock file for the device has the same _naming_ conventions as under 2.2, but the contents of the file MUST follow SCO's specs: the pid of the locking process must be stored in decimal ASCII with leading spaces, 10 characters, with a line feed following (11 character total file length). To write this to an opened file, use the C line: fprintf(fd, "%10d", getpid()); A lock file is considered by 2.3 to be expired NOT on the basis of time, but if the pid stored in the lock file is no longer running. If the file is not per the above spec., the lock is considered to be expired and is subject to removal. Page 37 of the bulletin gives a page of C code to test a lock file, remove it if expired, return if lock is valid, or set a lock if okay to do so. I just got this info from SCO and have not yet coded it in. If people are interested in my final results or want the full page of C code, please e-mail to me. I will e-mail back, or post if there is enough interest. Jeff Mo, Vision-Ease MIS department, St. Cloud, MN UUCP: {amdahl!bungia, uunet!rosevax, chinet, killer}!orbit!pnet51!vemis ARPA: crash!orbit!pnet51!vemis@nosc.mil INET: vemis@pnet51.cts.com