On May 11,  9:25am, Jim Wowchuk wrote:
> Subject: Re: LISTF, access proposal
> I would just like to echo Elbert E Silbaugh's comments about the LISTF,access
> proposal.
>
> 1)  An intrinsic could provide the means to get what ever data is desired,
>     in a format most suitable for the application.  This neither denies the
>     benefit provided by third parties like VESOFT, nor demands an
>     unsatisfactory parsing excercise.  The HP3000 should not need to become
>     AWK-ward! :)
Elbert, Stan, Evan and now Jim have suggested that a user-callable intrinsic
(probably new items to FLABELINFO (and maybe to FFILEINFO?) may be more
valuable to those who have asked for this functionality, than enhancing the
exiting LISTF[ILE] commands.  I want to do what best meets the needs our
customers within my relatively small time allotment, and I believed that adding
accessor info to LISTF[ILE] was the best way.  There have been enough comments
from respected 3000 experts that I am open to changing my mind.
 
If CSY only provides an intrinsic then you will have the following choices: 1)
write a program that calls the intrinsic, 2) buy a program that calls the
intrinsic (may need to buy support too?), 3) get the  program free from the CSL
(may not be an Interex member?, support?), 4) get a program free from somewhere
else (maybe even jazz, support?).  Are these *preferable* alternatives?
 
Remember, it you want to automate some task that involves knowing a file's
accessors and you *don't* have this intrinsic, then you will have to write
scripts that probably will parse the output of :listf,access.  This means that
CSY is not free to change/improve the output without possibly breaking your
script.
There is not enough time to do both an intrinsic and a command that calls this
intrinsic.
>
> 2)  If a CI command is still desirable, then provide two -
>     a basic one line/accessor abbreviated version and a full, whole
>     kit'n'caboodle, verbose version.
>
>     In considering the former, I can recall only two situations that occur
>     where I need this information:  a) I'm trying to *eliminate* all
accessors
>     to a file; or b) I'm trying to get another program to concurrently access
>     a file used by others.
>
>     For the first situation I need information to uniquely identify the user
-
>     a session number, pin number, and possibly the connection device.  After
>     all, I would prefer to ask them to exit the program than simply abort
>     them, so anything that can identify the physical user becomes helpful.
>
>     In the second situation, I need to know the flags for access - SHR/EAR,
>     LOCK, etc.
>
>     In the case of the verbose version, having a wealth of information can
>     be useful, but an overflowing gutful is just too much.  So for the
>     verbose version I believe it would be desirable if this information could
>     be limited not in its content but its quantity.  So I reckon you would
>     need the ability limit this to a specific user, session, or pin.
 
Thanks Jim.  These scenerios really help us make informed trade-offs in the
design of this ehnancement.
>
> But while we're on the subject, how about a way to do a LISTF on files in
> the NEW domain?  :)
 
How would this info be used?  What do you do today?  Any work arounds?  More
scenerios?!!
> ----
Thanks,
Jeff Vance, MPE Lab
 
>
> But while we're on the subject, how about a way to do a LISTF on files in
> the NEW domain?  :)
> ----
> Jim "seMPEr" Wowchuk           Internet:    [log in to unmask]
> Vanguard Computer Services     Compu$erve:  100036,106
>  _--_|\                        Post:        PO Box 18, North Ryde, NSW 2113
> /      \                       Phone:       +61 (2) 888-9688
> \.--.__/ <---Sydney NSW        Fax:         +61 (2) 888-3056
>       v      Australia
>-- End of excerpt from Jim Wowchuk
 
 
 
--
Jeff Vance