Hi Evan,
Thanks for the reply.
 
On May 10,  2:34pm, Rudderow, Evan wrote:
snip...
> 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.
JV: LISTFILE and LISTF use the same code after the command line is parsed.
JV: This common routine knows it was invoked by LISTF because there are some
JV: format differences between LISTF and LISTFILE.  So, there is no time
JV: savings.
>
>
> I liked Jeff Brown's ([log in to unmask]) suggestion to use a flag to indicate
> PINs which are remotely connected.
JV: Me too.
>
> <snip>
 
> >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...
JV: Can you give me an example?  I would look for the POS of "ACCESS=" and
JV: then for the POS of "," to find the access method.
>
> >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.
JV: I don't know how useful it will be in the above cases, but the record
number
JV: displayed is the value kept in one of the file system data structures
JV: (GDPD).  For a bytestream file the rec# is just the byte offset.  The value
JV: of displaying the rec# is to view progress.
>
> >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
JV: In 5.0 SHOWPROC supports a ;TRUNC and NOTRUNC option, with the default
JV: being TRUNC.  A '$" indicates the output line was truncated.  Do you
JV: prefer this method.  Note: trunc|notrunc probably needs to apply to all
JV: LISTFILE formats, not just ACCESS, which implies some more work.
 
> (By the way, can the name of the file that
> is being LISTFILEd wrap?
JV: Yes.
 
> Can we expect to see the access summary info
> (e.g.: 5 ACCESSORS,CHARED,3 R,2 W) in a constant position?
JV: No.
 
> 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.
JV: This is possible but consumes an extra line of output. (I guess in format
JV: choice 1) there is room without adding another line.)
>
snip...
> 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.
JV: I will consider this when it comes time to do beta for this enhancement.
JV: ...any volunteers???
 
 
 
--
Jeff Vance