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