Conference noted::hackers_v1

RMS possibilities :-
--------------------

1) RMS itself will not time out the request for me, since the 
timeout field in the RAB does not apply to network I/O.

2) It is not possible to just close the file, since it has an 
outstanding I/O request.

3) The only way RMS has of cancelling the I/O request is a 
SYS$RMSRUNDWN request, which will also close anything else I have 
open at the time in my programme.

4) RMS will terminate the I/O request with a failure status if 
the link to the remote node fails, so :-

DECnet possibilities :-
-----------------------

	Ruling out shutting the node down as being a rather 
drastic solution, I can disconnect the logical link.

1) First I have to find the number of the logical link to 
disconnect. The only supported way of doing this is to use NICE 
protocol to talk to NML on the local node, and search for logical
links that connect to my own PID. One of these will be the one to
the remote node that I wish to disconnect. A $GETJPI will
identify the links owned by me, and the remote node field will
identify which one to disconnect. 

2) To disconnect the link requires OPER privilege. If I use the 
NICE protocol link above, then I must either supply the user name 
and password of an account, or have a suitable proxy set up. 
These can be ruled out, since they mean giving OPER privilege to 
otherwise unprivileged users in order to run the programme.

3) The programme itself can be installed with OPER privilege. It 
cannot use this itself, since the supported NICE programme
interface is only through a DECnet link to another process. What
it can do, though, is to spawn a subprocess with OPER privilege,
and use the other documented, supported interface of an NCP
command line to disconnect the link. 


	Thus, to close the file from my programme, it only needs 
one process creation, two or three image activations, (depending
on what happens in NETSERVER processes), and the programme itself
being installed with OPER privilege. Maybe transparent DECnet I/O
is a little more opaque than I first thought. 
    

Hi Dave,
    	Now I know _exactly_ what you meant yesterday during lunch
    	when you asked me 'how to close a file'. So there was a bit
    	more to it huh! Included is a recent reply from the VAX-RMS
    	conference. Funny how similar questions pop up from various
    	places at similar times.
    	Let's hope someone knows a great hack to tackle your problem.
    Hein.
    
                 <<< STAR::BULOVA$DISK:[NOTES$LIBRARY]VAX-RMS.NOTE;1 >>>
                            -< VAX RMS Conference >-
================================================================================
Note 130.1            How to timeout network file writing?                1 of 1
QUARK::LIONEL "Free advice is worth every cent"      14 lines   4-MAR-1987 09:54
--------------------------------------------------------------------------------

    Your proposed solution won't work.  The channel you get in
    the STV is owned by exec mode and you can't touch it.  If you
    set FAB$V_UFO, you can use the channel, but can't do RMS I/O!
    There is NO way to cancel an outstanding RMS operation (other than
    by doing an RMS rundown, I suppose.)
    
    The only thing I can think of is to do asynchronous I/O, and if
    you don't get completion in a certain amount of time, give up on
    that file.  Not very clean.  Note that $OPEN/$CREATE are ALWAYS
    synchronous, and can indeed hang.  (Ditto $CLOSE.)
    
    The inability to cancel an outstanding RMS operation causes major
    headaches for the language RTLs.
    					Steve
    

.1> Maybe transparent DECnet I/O is a little more opaque than I first thought. 

    I believe the reason for the "hangs" is that MAIL opens SYS$NET
    thinking you want to send it some mail over the logical link.
    Even if you got the timeout to work (pretend for a moment that RMS
    supported timeouts on network connections) what would you do?
    Shut down the link, right?  Try again and you'll hang again in
    the same place.  You can't get past $ MAIL in LOGIN.COM no matter
    what DECnet and RMS options you select.  It really is a feature 
    that transparent network operations execute LOGIN.COM, and if the 
    remote end screws up it isn't _your_ fault.  A more black/white
    case occurs if somebody's LOGIN.COM contained:
    
    	$ IF F$MODE() .EQS. "NETWORK" THEN $ SET PROCESS/SUSPEND
    
    ... and then the user complained to you that your program "hung".
    Humbug!
    
      John

    	Yes. I know why MAIL would make it hang, which is why I quoted
    that as an example. I had not thought of the SUSPEND gimmick, but
    I would like to time out the link and disconnect in that case too, 
    rather than have my programme hang forever.
    
    	The programme connects to a large number of nodes in turn (say
    a whole Easynet area) and asks each one what X.25 connections it
    has. If RMS supported timeouts I would shut down the link and go
    on to the next node. I am not too bothered if a few do not respond,
    since that can be handled by 'phoning the system manager and asking
    him if he has an X.25 connection.
    
    	Another possibility is to run multi-threaded, with say 20 or
    30 files open at a time to different nodes, and doing asynchronous
    I/O. Then it would not matter if a few of them hung until programme
    exit ran them down, since it would by then have completed its report
    on all nodes that would talk properly. However, this rather negates
    the advantages of doing transparent DECnet I/O from a high level
    language. I might just as well use $QIO, since then I can do a timeout
    and $CANCEL.
    
    	It may be illegal to open SYS$NET from LOGIN.COM, but unless
    you can make that law binding on all Easynet system managers I would
    still like to close my file on a timeout.
    
    		Dave

    I support the idea of being able to time out a network link, and
    trust that RMS hads been made aware of this via VMSPHASE0.
    
    Lately more and more nodes around here have been refusing NML
    connections, probably in the name of "security".  You may find
    more and more nodes not responding to an automated poll.
    
    I don't know how important this program of yours is, but of course
    you realize that a true hacker could have his system give you
    false and misleading X.25 information.
    
      John

    Well, you could always have your timeout AST signal a need to do
    a $CMEXEC $CANCEL FAB$L_STV-from-$OPEN.  Which brings up a question,
    idly:  Can a user-mode AST call $CMEXEC and $CMKRNL without problem?
    I could doubtless figure it out if my brain weren't in the bedroom
    recharging..
    
    #ken	:-)}