Jeff Vance <[log in to unmask]> wrote:
 
<snip>
 
>Two issues here.
>1) when an accessor (process) does not have the file locked
>   should you see something simple like "None" or is it better to see the
>   Excl, Wait and Shr labels (consuming 2 extra lines) each with the value
>  "none"?
 
To simplify parsing (both for scripts and for the human eye) I favor having
the two extra lines -- the three line output will thus be consistent and
expectable.
 
>2) "none" vs. 0.  All of the lock values are names not counts, e.g. OPEN,
>   IO, FLOCK.   The *number* of processes holding locks is shown in the
>   Accessor summary line (L:4) and for each job/sess line.  It seem
inconsistent
>   to me to show a 0 as the value for no accessors when the remaining lock
>   values are names???
 
I see your point. OK.
 
<snip>
 
>> How about "sm_open" instead of "n/a"?
 
>I can do this but it is an educated guess that it was an sm_open.   It is
>conceivable that a process obtained a file system lock without sm_opening
the
>file.
 
OK, then how about something else like, say "other" -- to me "n/a" carries
the connoatation of "not applicable", and while that might be *strictly*
true in the situation described, it might be a bit confusing.  An
alternative to "other" might be "special"...
 
>
> >  #2 Do you like my proposed access values or are the names used by the
> :FILE
> >     command better?
 
<snip>
 
>My proposed values come from the Intrinsics manual and common usage.
 
Common usage in what context?  If the decision comes down to choosing value
names to be consistent with Intrinsics conventions vs. Command conventions,
then I'd favor using command conventions since the output is from a command.
 If the "common usage" you refer to is based on commands (other than FILE),
then go ahead with your proposed values -- I don't much care what we're
consistent with as long as we're consistent with something...
 
> >  #3 Do you like my proposed sharing values or the ones in the :FILE cmd?
 
Same argument as above.
 
Regards,
 
 -- Evan