Path: utzoo!utgpu!watmath!att!ucbvax!hplabs!hpfcdc!rer
From: rer@hpfcdc.HP.COM (Rob Robason)
Newsgroups: comp.sys.hp
Subject: Re: allocate/deallocate command wanted
Message-ID: <5570256@hpfcdc.HP.COM>
Date: 7 Aug 89 22:19:33 GMT
References: <210024@speclab.bgp-usgs.gov>
Organization: HP Ft. Collins, Co.
Lines: 43

> What happens if somone else writes to the tape while I am writing?
> Roger N. Clark

It seems like a spooling problem:  unfortunately the logical command
name (mt) is already taken.  I know of no solution to this problem
in any standards, though I agree it is a legitimate question.  One thought
that comes to mind is a "lock and do" command that would lock a specific
file (or group of files) and exec a shell to do the desired action.  In
the simple case it might look something like:

	NAME
	lad - lock and do command

	SYNOPSIS
	lad -f pathname ... command_string

	DESCRIPTION
	lad places an enforcement mode lock on pathname, then spawns a
	child process to execute command_string.  Upon completion of the
	child process, the lock is released.

This could be done simply with HP-UX Enforcement locking.
Unfortunately, that is not very universal yet.  I think that /usr/group
has proposed Manditory (Enforcement) locking, which would solve the
problem.

In HP-UX, the lad command would simply open, fchmod and fcntl 'pathname'
to create an enforcement lock, then call system('command_string'), then
fchmod and close 'pathname' to clean up.

There are some picky-uny user problems like getting the quoting right on
command_string to accept pipes, redirection and shell variable
expansion, but that could be handled with good documentation.  Another
area of care would be using WEXITSTATUS to inspect the return value of
system(3) to let the command exit status ripple back to the user.

Until the /usr/group proposal finds its way into an industry standard,
though, no such solution is likely to be very portable.  Any other
solution relies on cooperation between processes to observe advisory
locks, which is better than nothing, but far from bullet (or idiot)
proof.

Rob Robason