Some you may already know my voting strategy for enhancement requests; for
those who don't I filter the requests as follows:
 
1. Is the requested functionality already available as an add-on (either
from HP or a 3rd party); if so, then don't vote for it.
 
2. Is the requested functionality something that could be made available as
part of:
     - an enhancement to an existing add-on product?
     - a new add-on product?
     - a CSL contribution?
     - a program the average programmer with the average tool  set could
write?
If so, the don't vote for the enhancement.
 
The purpose, of course, is to filter the requests down to those which HP is
best equipped and best positioned to address: (namely those that would be
difficult (for whatever reason) for anyone else to address.
 
LISTF,ACCESS functionality is something that I've already got with MPEX;
nevertheless I'll offer my $.02 on this issue since this enhancement has
been requested and approved through the SIC voting mechanism.
 
Jeff Vance <[log in to unmask]> wrote:
 
>Below is the next revision of the ":LISTF, access" proposal.
 
<snip>
 
 
>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)?
>???????????????????????????????????????????????????????????????????????????
???
 
In my role as an SM, I prefer the command; in my role as a S/W developer I'd
prefer the programmatic interface -- but not AIFs (is that enough fence
straddling?).  Maybe instead of adding this capability to both LISTF and
LISTFILE you should add it to only LISTFILE -- give us yet another reason to
migrate to using the LISTFILE command.
 
<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)?
>???????????????????????????????????????????????????????????????????????????
???
 
The remote connection information *is* important -- more so than LDEV, which
is useless nowadays -- but it can wait for the next version.  However I do
have a concern about leaving that information to a later version: when that
functionality is implemented the output format would change -- and we all
know that, in the meantime, people will have written CI scripts (or
whatever) to parse the output from the initial version.  When the format
changes those scripts would no longer work and those people would be up the
creek.
 
I liked Jeff Brown's ([log in to unmask]) suggestion to use a flag to indicate
PINs which are remotely connected.
 
<snip>
 
BTW, I prefer choice 1.
 
>???????????????????????????????????????????????????????????????????????????
???
>Do you like lowercase labels or uppercase?  See LOGFILE1 1st accessor vs.
2nd.
>???????????????????????????????????????????????????????????????????????????
???
 
I like mixed case.
 
<snip>
 
>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????
>???????????????????????????????????????????????????????????????????????????
???
 
As I mentioned above, Ldev number is worthless; spooler ID for jobs sounds
good.
 
>ACCESS= Read, Write, Execute, Append, Lock, Save, Upate, Dirread. ",excl"
>        or ",ear" or ",share" appear after the access method.
 
Could these flags be made positional?  Doing so might make it easier for a
script to parse the output...
 
>REC #=  The record number being accessed by this PIN.
 
What kind of values will I see here for: TurboIMAGE datasets? Allbase/SQL
DBEFiles?  Bytestream files?, etc.
 
>PROG=   Fully qualified MPE or HFS filename (long names wrap)
 
Don't wrap long names!  Truncate them -- any script or program attempting to
parse the output will have to go through gyrations if it has to expect that
program names may wrap.  The number of line of output per PIN should be
constant to make parsing easier.  (By the way, can the name of the file that
is being LISTFILEd wrap?  Can we expect to see the access summary info
(e.g.: 5 ACCESSORS,CHARED,3 R,2 W) in a constant position?  Perhaps the
output format should be redesigned so that the program name is on it's own
line -- that would give it more character positions for HFS name than the
proposed format.
 
 
Stan Sieler <[log in to unmask]> commented:
 
>If the majority wants a command instead of a programmatic thing, then
>that simply means one thing:
>
>   they want a command.
>
>It DOESN'T mean:
>
>   the majority is right;
>
>With programmatic access, a trivial program can be written by almost
>anyone...and (almost certainly)...several will pop up in the CSL.
>
>With only a command form, *safe* *accurate* *efficient* programs cannot be
>written (for one, they'd be dependant on the format of the output, which HP
>has always warned people against depening on).
 
The next question to ask is, "Why do they want a command?"  After all, the
same functionality is available now -- from VeSoft at the very least,
probably from the CSL, and there's probably even a Nugget.  There are no
doubt many different answers to that question; but perhaps the overriding
one is:
 
     An HP supported command provides a consistent user interface.
 
And despite the warnings, users *will* depend on the output format remaining
constant; because they want a consistent user interface.  And they *will*
write scripts and programs that issue the command and parse the output --
even if an intrinsic (free and not-PM as opposed to an AIF -- not free and
PM) is available.
 
It's getting more like Unix every day, isn't it????
 
As a side issue, perhaps when the Lab enhances existing commands or
introduces new commands they should introduce them as stand-alone utilities
while issues of output formats, etc. are worked out.  I would expect the vuf
of such developing commands/utilities to begin, of course, with an 'X'.  The
nice thing about this approach is that interested users could investigate
and experiment with the command under development without having to load a
beta O/S and the lab would have to embed the new command deep in the bowels
of the O/S until operational and design issues are finalized.
 
While I don't agree that LISTF,ACCESS is even necessary, I would be remiss
if I did not express my appreciation to Jeff and the lab for their efforts.
 
 -- Evan