In article <[log in to unmask]>,
[log in to unmask] says...
>
>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.
>
> ... snip ...
>
>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)?
>???????????????????????????????????????????????????????????????????????????
???
******************************
How about just the flag that the pin is remotely connected. Then, if
someone wants additional info they can go get it by exception rather
than always.
******************************
>
>
>-----------------------------------------
>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.
>???????????????????????????????????????????????????????????????????????????
???
>
**************************
I usually like lowercase labels, but what is important to me
is the ability to visually easily distinguish between the labels
and the data.
**************************
>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????
>???????????????????????????????????????????????????????????????????????????
???
**************************
LDEVs are now worthless for us since we use almost entirely
network connections, and have only the console directly
connected. It'd be nice to have spoolfile id for the $STDLIST.
**************************
>
>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]
***************************
If it gets that cryptic it won't be useful to anything other
than a program viewing it and possibly a very experienced user
with that output. Ughh!
***************************
>
> 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
*****************************
Could you provide a sort parameter, so that the user can
choose from a set of sort fields, e.g., by job number, or
by file name, or by disk, etc.?
*****************************
Jeff Brown
[log in to unmask]
|
