Conference noted::hackers_v1

You can use $ANAL/SYSTEM to use SDA on the current in-memory copy of VMS.
Then use (I think) the command SHOW PROCESS/CHANNEL to find out what files
any particular process has opened. 

This requires CMKRNL privilege.  You could write your own code to do the
same thing, but it would need some privilege to read the info from the P1
space of another user.  (Probably CMKRNL to use special kernel mode AST's).

You can also use $SHOW DEVICE/FILE to see which files on a disk have been opened
by which processes.  I suppose one could spawn sub-processes to do this and also
$ SHOW DEVICE/MOUNT and $SHOW SYSTEM, writing the results to files.  Then
your program could parse these files to determine what you want to know.

I like the first method best.  Any hacker worth his/her salt will have no 
trouble copying the method used by the code in SDA.

One way would be to start with  IOC$GL_DEVLIST (the list head for
all devices DDB), this points to the device UCB, in the UCB test
the DEVCLASS for DC$_DISK, if not disk then next DDB
When you have the UCB for a disk class device the offset UCB$L_VCB
points to the Volume Control Block VCB, in the VCB the offset
FCB points to a list of File Control Blocks for all files open
on this disk device, the FCB gives you the file FID and the offset WCB
(Window control block) gives you the Process PID that has the file open,
test pid and if its the one you want then translate the FID to a file
name (i think there is a system routine to do this) and report it !!

Does this make any sense ?

peb

    RE:.1
    
     I know of all this but I'm looking for a way to do this with code
    how du it direct (I hope this is faster).
    
    I wrote a progamm similar to the $sh proc/cont/id=nnnn but it returens
    more info and want to switch the display to see what files the
    displayed user has opend.
    
    
    RE:.2
    
    This is for what I'm looking but I dont know anything about
                       IOC$CL_xxxxx, UCB, FCB 
    
    has anybody an exambple how to use it in BASIC >and< where I can
    finde info in manuales
    
    
    
    Frido!
    

>    This is for what I'm looking but I don't know anything about
>                      IOC$CL_xxxxx, UCB, FCB 
>    has anybody an example how to use it in BASIC >and< where I can
>    find info in manuals


I picked up my info about such things from the VMS internals course,
the IDSM , Vmsnotes files and asking a lot of silly questions (ask JC)
I don't think there is one place for such info (if there is please let
me know)
As for doing the above in Basic, it may well be possible but 
I don't think I would like to try it, to get at such stuff you will
have to be in Kernel mode (or maybe exec), MACRO is much better at this
type of thing

Looking at my reply (-2) I suppose the HOT_FILES prog in the tuneing
notes file must use the same method of access, since when you get down
to the WCB for a file , that gives you the read/writes on it
Hummm....

PEB

    re 358.2 ...
    
    i assume the idea is to show files opened by a user regardless of
    what member of a cluster he may be on, right?  if this is what you're
    after i don't think IOC$GL_DEVLIST is going to do it for you because
    it won't find the devices mounted clusterwide.
    
    i did something similar to this and had to start with SCS$GQ_CONFIG
    which pointed to a list of SBs and the SBs pointed to the DDBs. 
    from here if the DDB pointer isn't zero then you can continue as
    in note 358.2.
    
    - marty
    

    BTW, you could always write the code in MACRO and call it from
    BASIC.
    
    One of the gotcha's is that you'll need to raise IPL so noone
    changes the I/O database on you whilst you are chasing pointers.
    BLISS might have a SETIPL builtin, and MACRO has a macro that
    does it, but I doubt any other popular languages (Pascal, Fortran,
    RPG) have it.
    
    	KC

    re: .-1
    
    > but I doubt any other popular languages (Pascal, Fortran, RPG)
    > have it.
    
    Why would anyone want to raise IPL from within an RPG program???
    
    Anyway, BASIC does not have any built-ins to raise IPL, and I don't
    know of any way to even get into kernel mode without calling a MACRO
    subroutine. I'd LOVE to see an example (if anyone can do it without
    calling another language)... Besides, BASRTL probably can't deal
    with raised IPL's anyway, system calls get called within it.
    
    All I have examples of are kernel-mode subroutines which are called
    from within a VAX-BASIC program. No reason you can't call them from
    any other native-mode language, either.
    
    /pjh
    

    Well, I've used $CMEXEC and $CMKRNL within Pascal, but Pascal doesn't
    have MFPR and MTPR/setipl capabilities, although you could write some
    macro code to do it, via doing their own SETIPL/DSBINT and then munging
    the call frame so that it doesn't get re-set on return. (I don't
    remember - will a RET from a procedure which was called at IPL 0
    and then raised it to say.. IPL$_SYNCH return it to 0?)
    
    Just keep in mind what can and can't be done at a more privileged
    access mode and elevated IPL!  I'm not familliar with BASIC's generated
    code, but from the talk it's heavily laden with RTL/run-time-system
    calls.  This could definitely be a problem, while I know Pascal
    usually generates pure code (i.e. no RTS calls) unless you do something
    like I/O or such.
    
    					-mjg
    

yes RET will restore IPL

one problem I have found is that tho I can get the FID's
of the open files from the VCB FCB etc, How can I translate this to
a file file while in Kernel mode ?? calling QIO to do this dont work



peb

> yes RET will restore IPL
    
    RET does NOT restore IPL.  Either use MTPR or REI, which ever is
    appropriate 
    
Phil    

Isn't the question backwards?  FILEs don't open USERs -- USERs open FILEs.

:^)

re .-1

> Isn't the question backwards?  FILEs don't open USERs -- USERs open FILEs.

    That depends on the user...

Harley :-)

    re: .10
    
       Thanks.  In any code I've written which raises IPL, I always
    ENBINT or whatever appropriate MACRO seemed good before exiting
    - after all, you're really only supposed to keep IPL raised while
    you NEED it, and then get it back down, ASAP!  At least that's the
    philosophy which has been expressed to me.
    
    
    					-mjg
    
    (Boy, that first sentance in .8 was awkward!  Sorry...)

    I know this topic hasn't been active for a while, but I am interested
    in the same as .1, and I don't see a clear answer yet.
    
    Surely the cluster/single machine problems go away if you can start
    from the processes view of things.  Is there no data structure you
    can look-up in the process header or other process data areas, which
    can lead you to a list of channels/files?  Even if it is only channels,
    you can surely cross-correlate to get filename from INDEX.SYS. 
    I would like to be able to do this stuff in a "supported" fashion.
    IE. a method which can be made public, and is not likely to change
    in the future (without at least warning or documentation).
    
    Is this possible, or just "pipe-dreams"?
    
    Hopeful, Glenn

>    Is this possible ?

Yes

How hard ? medium


*ALL* the stuff about open files is contained in the processes
P1 space (CCB$L_CCBBASE (Sp)), so you must use an ast to
get the information from the target process and then 'send' it
to you

The structure *above*  ccbbase is a list of CCB (channel Control Blocks)
one per file (the file mode is stored in this as mode+1, so you
can tell the difference between a kernel mode channel (=0) and
an unused block) from the CCb you can such things as the ucb for
the device the channel is open on etc etc

There is at least one example of scaning the CCB list and converting
it to a full file spec in this notes_file  (but its poorly written),
its in the note about setting up Control F & V keys
(note title ~ Out of Band Ast  (approx))

So all you have to do is send the target process an ASt, this will
send you back all the CCB's, then convert to a file spec



Peter Bailey           



Ps I *LOVE* workstations !!

If you want to know what files a process has open, look into FILES
available from the Software Tools Clearinghouse (toolshed) on METOO.

tom_p