There are 3 steps that could be done to provide accessor info:
 
(1) An intrinsic that provides all info. Then almost anyone can write
    a routine to get whatever data they want for whatever reason.
    This reduces the need to have an output that is parseable.
    The only reason we parse output is because we have no other means
    of getting the data (without PRIV mode).
    Parsing ASCII output is (almost) stupid -- when you should have been
    able to get it 'direct' (via an intrinsic)
 
    I do not view this as extra effort, since our beloved HP SW labbies
    need to write code to get the stuff anyway, they may as well put it
    in an environment (intrinsic) that all (incl HP) can use as desired.
 
(2) An abbreivated output that shows:
 
      FILENAMESPEC (# accessors, shared, x R, x W)
           J/S#  LOGONNAME  CONNECTION  PIN  PROGRAM
           ...
           ...
 
    Good examples have already been provided by others in this thread
 
    This is merely mediocre use of the enhanced intrinsic. But now a
    part of the LISTF command that is available to OP, SM, or R/W access
    of the FILE
 
(3) Provide a verbose output that shows everything. This is merely
    judicious use of the enhanced intrinsic.
    As mentioned in other threads, if it gets too cryptic, you may as
    well do a core dump and let a person decipher the encrypted stuff.
    The reason to print it out is so we can read it.
 
The CONNECTION could be an LDEV, network node, or whatever the
industry dreams up tomorrow. It would be OK if the network node is not
available on first release, I suppose.
 
Elbert