UUCP help, SCO 2.3 HDB dialin/dialout no good - repost

[Jeff Mo]

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 at nosc.mil
INET: vemis at pnet51.cts.com