Hello All,
Below is the next revision of the ":LISTF, access" proposal. There are 3
output formats for you to review. The data is the same for all formats. There
are several questions surrounded by rows of "???????????????????????????".
Your responses will impact the final command behavior.
I have received the following feedback on my 1st proposal (dated Oct '94):
a) "allow anyone who has SM or OP capability, or has read or write access to
the target file, the ability to see all accessors". This is suppossed to be
consistent with MPEX. Read/write access can be granted via an ACD or via
'regular' matrix security. If you have only eXecute access to the file then
you can not see its accessors (OP excepted).
b) "add accessor info to FLABELINFO and finfo() first - do a command later".
AIFPROCGET item 2065 returns ProcessIDs for all accessors to a file, so
there exists a programmatic interface. I am working on enhancing the :LISTF
and :LISTFILE commands first.
??????????????????????????????????????????????????????????????????????????????
Is this OK? Do the majority of you (real SMs, not just s/w developers)
prefer accessor info via :LISTF, or via a programmatic interface (but not
both)?
??????????????????????????????????????????????????????????????????????????????
c) "show info on who has what locked". OK, see examples below.
d) "show DBOPEN modes". I am defering this.
"Show current record number". OK.
e) "provide tabular output". "Do not display cryptic output".
f) "condense the output to one line per accessor to simplify parsing the
output when redirected".
g) "there is no output format that will please everyone". Amen!
You have 3 choices below. There have been suggestions to allow for
user-defined, customizable output. Great idea, but this would
*considerably!!* delay implementation (maybe 6-12 months or more!).
h) "what about remote connections?" Well, for now I was going to just
display traditional server-based data (user.acct, pin, ldev, etc.).
The user could then pass the shown PIN to another command (or evaluator
function) to get remote connection info. We are designing/coding
the "Who's Connected to the 3000" project now and there is a possibility
of some leverage between LISTF,access and Who's connected. I could
detect the pin is remotely connected and get addition info, such as
IP address or domain name. Then I need some room to display it!
??????????????????????????????????????????????????????????????????????????????
Is it very important to have this info integrated into LISTF,access? Is
it worth a delay (approx. 1-2 months)?
??????????????????????????????????????????????????????????????????????????????
-----------------------------------------
Choice 1 (column format sort of like ,3):
-----------------------------------------
********************
FILE: LOGFILE1.LOGGING1.SYSTEM12 (5 ACCESSORS,SHARED,3 R,2 W)
USER: JOBNAME8,USER5678.ACCT5678,GROUP678
JSID: #S12345 PROG: MYPROG78.MYGRP678.MYACCT78
PIN: 12345 ACCESS: Read,share
LDEV: 12345 LOCKS-- FLOCK: Yes-share
REC#: 1234567890 OPEN: Yes-share
GUFD: No
User: JOBNAME8,USER5678.ACCT5678,GROUP678
JSid: #S12345 Prog: RSPOOL.RSPOOL.SYS
Pin: 104 Access: Write,share
Ldev: 12345 Locks-- FLOCK: No
Rec#: 12 OPEN: Yes-share
GUFD: Yes-wait[2]
USER: FRED,MGR.PAYROLL,PUB
JSID: #S40 PROG: /usr/local/bin/bsd/tools/some_program.exe
PIN: 244 ACCESS: Read,share
LDEV: 77 LOCKS-- FLOCK: No
REC#: 379 OPEN: No
GUFD: Yes-wait[1]
USER: JSPOOL,RSPOOL.SYS,RSPOOL
JSID: #J15 PROG: RSPOOL.RSPOOL.SYS
PIN: 244 ACCESS: Read,share
LDEV: 10 LOCKS-- FLOCK: No
REC#: 756 OPEN: No
GUFD: No
USER: JOBNAME8,USER5678.ACCT5678,GROUP678
JSID: #S12345 PROG: MYPROG78.MYGRP678.MYACCT78
PIN: 407 ACCESS: Update,share
LDEV: 12345 LOCKS-- FLOCK: No
REC#: 1005 OPEN: Yes-share
*GUFD: Yes-exclusive
********************
FILE: /bin/awk (2 ACCESSORS,SHARED,2 R)
USER: CATHY.DEVELOP,CI
JSID: #S12 PROG: /bin/awk
PIN: 209 ACCESS: Read,share
LDEV: 228 LOCKS--*FLOCK: Yes-exclusive
REC#: 1234567890 OPEN: No
GUFD: No
USER: JCOMP,MBETOOLS.BUILD,PUB
JSID: #J8 PROG: /bin/awk
PIN: 81 ACCESS: Read,share
LDEV: 10 LOCKS-- FLOCK: Yes-wait [1]
REC#: 0 *OPEN: Yes-exclusive
GUFD: No
??????????????????????????????????????????????????????????????????????????????
Do you like lowercase labels or uppercase? See LOGFILE1 1st accessor vs. 2nd.
??????????????????????????????????????????????????????????????????????????????
Note: For LOGFILE1 the 1st, 2nd and last entries repeat the same USER,
JSID and LDEV values because 3 different processes within the same
session are accessing the file. Except for those fields the remaining
data is process (PIN) specific.
Each field is described below:
FILE= The fully qualified MPE or HFS filename whose accessors you are
interested in.
(3 R)= The FLAGS line seen in a :listf,3. # of readers, # writers.
USER= The full logon user id ([jsname,]user.acct,group).
JSID= The job or session number.
LDEV= The Logical Device Number
??????????????????????????????????????????????????????????????????????????????
This isn't very useful for jobs. Would you prefer that the
Spoolfile ID (eg, #O123454) is listed rather than ldev for jobs????
??????????????????????????????????????????????????????????????????????????????
ACCESS= Read, Write, Execute, Append, Lock, Save, Upate, Dirread. ",excl"
or ",ear" or ",share" appear after the access method.
REC #= The record number being accessed by this PIN.
PIN= Process ID Number. This is snapshot data and thus the listed PIN
may be dead by the time you see the output!
PROG= Fully qualified MPE or HFS filename (long names wrap)
LOCKS= broken down to the 3 locks displayed.
- FLOCK is usually a non-shareable semaphore that is obtained when a
program calls the FLOCK intrinsic. However, our directory uses FLOCK
to lock directory files and converts it to a shareable semaphore.
The FLOCK values can be "Yes-exclusive", "Yes-share", "Yes-wait [#]"
and "No". An astrisk indicates this process is the exclusive owner.
- OPEN is a shareable semaphore used only by the operating system.
OPEN values can be "Yes-share", "Yes-exclusive", "Yes-wait [#]",
and "No". Since the open semaphore may be share there can be many
owners. However it can also be locked exclusively, and thus there
can be waiters. An astrisk indicates this process is the exclusive
owner.
- GUFD (maybe someone can suggest a better name?) is a non-shareable
semaphore only obtained by the system. GUFD values are "No",
"Yes-exclusive" and "Yes-wait [#]". Again, an asterisk indicates
that this process has the GUFD locked exclusively.
A process can have many combinations of the above semaphores
locked, and there could be an asterisk at each lock.
wait= This accessor is waiting on one of the semaphores defined above.
The # indicates their position in the wait queue. Note that the
accessors displayed are not necessarily in wait order for a given
lock.
??????????????????????????????????????????????????????????????????????????????
How important is knowing the wait queue number? Is it worth delaying LISTF
access by, say, 1-2 months???? How would you use this info??
??????????????????????????????????????????????????????????????????????????????
--------------------------------------------------------------------
Choice 2 (cram as much info as possible into the fewest # of lines):
--------------------------------------------------------------------
********************
LOGFILE1.LOGGING1.SYSTEM12 (5 ACCESSORS,SHARED,3 R,2 W)
#S12345 JOBNAME8,USER5678.ACCT5678,GROUP678 Ldev: 12345
#P12345 Read,shr,1234567890 MYPROG78.MYGRP678.MYACCT78
FLOCK: Yes-shr, OPEN: Yes-shr, GUFD: No
#P104 Write,shr,12 RSPOOL.RSPOOL.SYS
FLOCK: No, OPEN: Yes-shr, GUFD: Yes-wait[2]
#P407 Update-shr, 1005 MYPROG78.MYGRP678.MYACCT78
* FLOCK: No, OPEN: Yes-shr, GUFD: Yes-excl
#S40 FRED,MGR.PAYROLL,PUB Ldev: 77
#P244 Read,shr,379 /usr/local/bin/bsd/tools/some_program.exe
FLOCK: No, OPEN: No, GUFD: Yes-wait[1]
#J15 JSPOOL,RSPOOL.SYS,RSPOOL Ldev 10
#P244 Read,shr,756 RSPOOL.RSPOOL.SYS
_NO LOCKS_
********************
/bin/awk (2 ACCESSORS,SHARED,2 R)
#S12 CATHY.DEVELOP,CI Ldev: 228
#P209 Read,shr,1234567890 /bin/awk
* FLOCK: Yes-excl, OPEN: No, GUFD: No
#J8 JCOMP,MBETOOLS.BUILD,PUB Ldev: 10
#P81 Read,shr,0 /bin/awk
* FLOCK: Yes-wait[1], OPEN: Yes-excl, GUFD: No
Note: all processes for each job/session appear under the job data line.
An "*" indicates that this process is the exclusive owner of at least
one lock. Fields are spearated by 1 or more spaces, but all fields are
not in any row/column fixed positions. This decreases the chances of a
long program name from wrapping. The record number isn't very obvious.
The lock info is the same as for choice 1, except that some abbreviations
are used. Also if the PIN has no locks then "_NO LOCKS_" is displayed.
??????????????????????????????????????????????????????????????????????????????
The locks line can display "FLOCK: No, OPEN: No, GUFD: No" rather than
"_NO LOCKS_". Is this better? (parsing output perspective?)
??????????????????????????????????????????????????????????????????????????????
I could eliminate the locks line by using more abbreviations:
FLOCK-Yes,shr --> Fs
FLOCK-Yes,excl --> Fe
FLOCK-No --> f
FLOCK-Wait[#] --> F#
Ditto for OPEN and GUFD. Combination examples:
fog --> no locks held
FsOsg --> FLOCK-shr, OPEN-shr, no gufd lock
fOeG1 --> no flock, OPEN-excl, GUFD-wait [1]
So the 1st 2 accessors listed above could be reduced from:
#S12345 JOBNAME8,USER5678.ACCT5678,GROUP678 Ldev: 12345
#P12345 Read,shr,1234567890 MYPROG78.MYGRP678.MYACCT78
FLOCK: Yes-shr, OPEN: Yes-shr, GUFD: No
#P104 Write,shr,12 RSPOOL.RSPOOL.SYS
FLOCK: No, OPEN: Yes-shr, GUFD: Yes-wait[2]
to:
#S12345 JOBNAME8,USER5678.ACCT5678,GROUP678 Ldev: 12345
#P12345 Read,shr,1234567890 FsOsg MYPROG78.MYGRP678.MYACCT78
#P104 Write,shr,12 fOsG2 RSPOOL.RSPOOL.SYS
??????????????????????????????????????????????????????????????????????????????
Is it important to have 1 line per PIN accessor?
??????????????????????????????????????????????????????????????????????????????
------------------------------------------
Choice 3 (Combination of choices 1 and 2):
------------------------------------------
********************
LOGFILE1.LOGGING1.SYSTEM12 (5 ACCESSORS,SHARED,3 R,2 W)
#S12345 JOBNAME8,USER5678.ACCT5678,GROUP678 Ldev: 12345
PIN: 12345 Read,shr REC: 1234567890 PGM: MYPROG78.MYGRP678.MYACCT78
FLOCK: Y-shr OPEN: Y-shr GUFD: No
PIN: 104 Write,shr REC: 12 PGM: RSPOOL.RSPOOL.SYS
FLOCK: No OPEN: Y-shr GUFD: Y-wait[2]
PIN: 407 Update,shr REC: PGM: MYPROG78.MYGRP678.MYACCT78
* FLOCK: No OPEN: Y-shr GUFD: Y-excl
#S40 FRED,MGR.PAYROLL,PUB Ldev: 77
PIN: 244 Read,shr REC: 379 PGM: /usr/local/bin/bsd/tools/some_
program.exe
FLOCK: No OPEN: No GUFD: Y-wait[1]
#J15 JSPOOL,RSPOOL.SYS,RSPOOL Ldev: 10
PIN: 244 Read,shr REC: 756 PGM: RSPOOL.RSPOOL.SYS
_NO LOCKS_
********************
/bin/awk (2 ACCESSORS,SHARED,2 R)
#S12 CATHY.DEVELOP,CI Ldev: 228
PIN: 209 Read,shr REC: 1234567890 PGM: /bin/awk
* FLOCK: Y-excl OPEN: No GUFD: No
#J8 JCOMP,MBETOOLS.BUILD,PUB Ldev: 10
PIN: 81 Read,shr REC: 0 PGM: /bin/awk
* FLOCK: Y-wait[1] OPEN: Y-excl GUFD: No
Note: like in choice 2, this output has all processes for the same job/session
appear together. It uses mostly fixed column positions and some labels.
The PGM field will wrap-around if the program name is > 29 characters.
I guess my personal favorite (for now) is choice 1. Choice 2 may be easier to
parse its output, but seems less readable to a human. Choice 3 is ok, but
I think the PGM field is too short, and it is still less humanly readable
than choice 1 (IMHO).
Please give me your comments and I will incorporate them into (hopefully) the
final proposal. Thank you for your time!
Jeff Vance, MPE Lab
|
