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]