On Jun 13,  5:53pm, Rudderow, Evan wrote:
 
> >--------------------
> >Format 9 ("locks"):
> >--------------------
> >
> >:listfile logfil@, locks; seleq=[access=TRUE]
 
oops...this should read ;seleq=[accessed=true]
                                      ^^
maybe later we can add  [access=read|write|update...]
                        [locked=true],   etc..
 
> >********************
> >LOGFILE3.LOGGING1.SYSTEM12
> >  5 Accessors(O:5,R:4,W:1,L:5),Share,Remote
> >#S12345  JOBNAME8,USER5678.ACCT5678 R:2,W:1,L:4          LDEV: 12345
> > #P12345 ACC:  Read-shr       (A2345678.B2345678.C2345678)
> >  LOCKS--Excl: FLOCK,IO       REC#: 1234567890123456789  FNUM: 12345
> >         Wait: none
> >         Shr : none
> > #P210   ACC:  Read-shr       (CI.PUB.SYS)
> >  LOCKS--Excl: none           REC#: 1005                 FNUM: 15
> >         Wait: FLOCK
> >         Shr : OPEN
> > #P224   ACC:  Update-EAR     (/bin/vi)
> >  LOCKS--None                 REC#: 120                  FNUM: 15
> >
>
> Can the job/session line tell us how many PINs will be displayed?
 
Right now it doesn't because I thought it is more important to know the
number of readers/writers rather than the number of pins. Also a process
can open the listed file more than once - this PIN will appear twice in
my formats.
 
> That
> might ease parsing.  So would using three lines even when no locks are held
> (as is true of the last process in the preceding example.  Please use "0"
> instead of "none".
 
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"?
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???
 
> >:listfile @.work,9;seleq=[accessed=TRUE]
> Is it [accessed=TRUE] or [access=TRUE]?
 
It should be [accessED=true].
 
> And I wonder if sometime down the
> road I might want to be able to specify finer granularity on the access
> and/or lock type?
 
That would be nice.  The code is extensible to these kinds of enhancements.
 
snip...
>  Next, the current record number for this PIN is shown. Last
> the
> >file number is seen (note: if the process has sm_opened the file the
> "FNUM:"
> >field will be "n/a").
>
> 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.
 
>
> >  #2 Do you like my proposed access values or are the names used by the
> :FILE
> >     command better?
> >     Proposed "ACC:" values are:             :FILE cmd ;acc= values are:
> >     ---------------------------             ---------------------------
> >       Read  (r-only, recptr starts at 0)      In
> >       Write (w-only, eof starts at 0,         Out
> >              previous data is deleted)
> >       Update (read/write, recptr=0, eof not   Update
> >               changed, can call fupdate)
> >       Save (write, prev data not deleted,     OutKeep
> >             recptr=0, eof not changed)
> >       Append (write, recptr=eof)              Append
> >       R/W (recptr=0, eof not changed, can't   InOut
> >            call fupdate)
> >       Execute (read/write, recptr=0, eof not  n/a
> >                changed, need PM)
> >       Readir (read contents of a directory)   n/a
> >       Undefined (all sm_opens)                n/a
>
> While I generally like the proposed values better I think it makes sense for
> consistency's sake to use the FILE command values.  Unless, of course,
> there's something else that uses the proposed values; then you can be
> consistent with whatever that is...
 
My proposed values come from the Intrinsics manual and common usage.
 
>
> >  #3 Do you like my proposed sharing values or the ones in the :FILE cmd?
> >     Proposed -sharing values are:           :FILE cmd values are:
> >     ----------------------------            ---------------------------
> >       shr                                     shr
> >       excl                                    exc
> >       EAR                                     EAR
> >       multi                                   multi
> >       gmulti                                  gmulti
> >       EAW (excl-allow-w)                      semi
> >       sexcl (sys-excl)                        n/a
>
> Again, for consstency go with the FILE command values.
 
I have modified this proposal to use "semi" to cover both EAR and
SEMI sharing.  SEMI converts to EAR for non-MSG files.
 
Thanks for the comments.  I actually haven't received much feedback.
This is either because you are tired of dealing with this command, or
you like it, or its so far off you don't have the time to set me straight.
 
But thanks anyway,
 
Jeff Vance, MPE Lab
 
--