At 06:23 PM 5/4/95 PDT, Jeff Vance wrote:
>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.
>
>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)?
>??????????????????????????????????????????????????????????????????????????????
I support your plan to enhance the command(s) first. I believe that that is
in the best interests of the largest portion of your customers. For me
personally, it would be better to have the intrinsics modified first, but I
understand...
 
>
>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)?
>??????????????????????????????????????????????????????????????????????????????
It doesn't matter to me. Can't you add it later?
 
 
>
>I guess my personal favorite (for now) is choice 1.
Choice 1 wastes too much vertical space. If you have a lot of accessors,
you're going to paging up and down areal lot on a 24 line terminal.
 
 
>Choice 2 may be easier to parse its output, but seems less readable to a
human.
I don't think the tradeoff in legibility is worth the small gain in
parseability.
 
 
>Choice 3 is ok, but I think the PGM field is too short, and it is still
less humanly readable than choice 1 (IMHO).
I found #3 to be quite readable and easily parseable as well. If long
program file names were wrapped to continue in the same columen in which
they began, that might help.
 
 
Have fun!
 
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:                                                                           :
: Scott Herman          [log in to unmask]   Yale-New Haven Hospital
:
: Dept of Lab Medicine                                       20 York Street :
: (203) 785-2449                                       New Haven, Ct. 06504 :
:                                                                           :
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::