Conference noted::hackers_v1

    Rather than stopping the process (with STOP/ID ?) you could try
    using $FORCEX system service. This would allow the condition and
    exit handlers for the application to run. I would hope that a database
    application would ensure that it tidies up in the exit handler.
    
    Andrew Palka

    Is there any way (Such as the send command file) to broadcast
    an escape sequence to load his answer back buffer with the 
    appropriate commands, then get the terminal to send the 
    answerback message thus logging itself off?
    
    				Something to ponder...
    
    					al
    

    If you're on some sort of terminal switching system, how about a
    MICOM hack to reassign the terminal to yours so you can cleanly
    exit it manually?
    
    -joet

	    [RE .2]:  Legend has it that such an escape sequence exists,
	but I have no idea what it is (if, indeed, it does exist).  If
	you insist on such a hack, you could plug a loopback connector
	into the terminal's printer port (assuming it has one) and send
	the following text to the terminal:

		<ESC>[5i<CTRL/Y><CTRL/Y>logout<ESC>[4i

	(Some use <ESC>[?5i and <ESC>[?4i here, but I don't know when or
	why it is appropriate.)
	    Nasty stuff.
			<_Jym_>

    
    RE .1 
    	Thanks, that's what the toolshed told me too.  
    
    re: .2
    	An idea, but where Jym states in .4, the CTRL/Y would definately
    do some damage to the data base, that we're so aufully trying to
    keep from damage.  Other ideas ??
    
    RE: .3 
    	Well, we have a MICOM, but from the MICOM, the users go to 
    DECSA's.  Maybe a DECSA hack ?  Something else to ponder maybe ??
    
    Matt :^)
    ( Thanks for the help though. )

    A simple solution is to make all the terminals /DISCONNECT.
    Assuming everyone's going in thru a LAT, use LCP DELETE PORT to
    delete the LAT port, then set your UIC to the user's, CONNECT
    to their terminal, and exit the program and log them out.
    
    If they're not on a LAT, a simple program run by a person with
    SHARE priv can force the disconnect. (An undocumented QIO function).
    	-Rick

    RE .6
    
    I wrote a program that did a disconnect QIO. The problem is that
    this QIO seemed to be queued until the current READ QIO on the terminal
    was completed. Not much use if the user isn't going to type anything!
    (This was some time ago, so VMS may have fixed this by now, perhaps
    a suitable logical name followed by a DISCONNECT command would do
    this).
    
    Of course you can't disconnect a user who has logged in via SET HOST.
    
    Andrew
    
    Andrew

    	A few eeks ago I saw a similar not in VAXWRK::VMSNOTES.
    A 'system manager' wanted to be able to send stuff into users'
    type-ahead buffers so he could force an orderly exit from
    MAXCIM.
    	Apparently, this person was contacted by someone who knew
    how to do this, although the actual method was not posted in
    the notesfile.
    	I suggest reading through VMSNOTES with a SEARCH for MAXCIM.
    Then maybe you can contact the previous guy and find out what he
    ended up with.
    
    	mike

    Maybe I'm naive, but with enough muscle, can't you do anything on
    a VMS system?
    
    If I could get to the application code, I would first do something
    simple there.   If not, try some simple operating system hack
    (like $FORCEX).   Last resort would be something like hacking the
    terminal driver to force the I/O to complete.   
    
    With CMKRNL and alot of VMS sources, you should be able to do 
    anything the OS can do.  
    
    	KC

    Thanks for all the tips.  Yes, they will be going through DECSA's,
    and we have the PRIV's for it.  That sounds interesting also.  
    
    RE: VMSNOTES and MAXCIM - probably our sys$manager, but I may be
    wrong.  He hangs around the VMS and other closely oriented files.
    
    Thanks again for all your help, and keep them hack's a comin' !
    
    Matt :^)

    Digital Review, April 1986, has an article about CONTRL, from Clyde
    Digital Systems Inc. (Provo, Utah), a program which lets system
    manglers "tap in" to termnal lines.  The manager can watch the user's
    screen and override the user's keyboard.
    
   "CONTROL works by inserting a pseudo device driver called UCA into
    the input/output stream of the device being monitored (Fig. 1).
    Normally VMS routes all terminal I/O data through the terminal class
    driver (TTDRIVER) and then through the terminal port driver (DZDRIVER
    for DZ11...)  When CONTROL is activated, however, UCA splits or
    merges terminal data streams passing between the class and port
    drivers..."
    
    Fig. 1 shows UCDRIVER just below TTDRIVER and simultaneously talking
    to the device drivers {DZ,YC,LT}DRIVER for the Master Terminal and
    Slave Terminal.
    
    Well, there's a commercial hack!  Maybe you can take inspiration
    from it.
       fred

    The problem with the CONTROL approach is that it won't work with
    terminal devices that don't use the PORT/CLASS approach (like the
    RT terminals from SET HOST)...
    	-Rick

    How do I stop one of my own processes which is in the STATE of RWAST
    (what ever that means?).   I've tried 'STOP processname' and
    'STOP/ID=nnnnnnnn' but nothing seems to work!  Any suggestions?

    The RWAST State indicates that your job has gone into a MUTEX wait,
    and in this case its waiting for a R/W on a AST. The reason that
    STOP/ID doesn't work is that the process in put into this wait state
    by VMS in Kernel Mode and the STOP/ID only generates an Executive
    Interupt (or the jobs in Exec and the Stop generates a Supervisor
    Level, I don't remember and don't have an internals manual handy).
    
    Anyway in English, when a job enters a MUTEX wait, unless the cause
    of job entering this state is fixed, you can't kill it with any standard
    VMS System Service, DCL Command whatever. This because of the Event
    Flag mode difference, Your request to kill the process in made in
    a less priv mode or, at the most, equal mode to one the job is in,
    so the kill request queues up another AST. But, some internal VMS
    table munging does happen, The job will still appear on SHO SYS,
    but if you use F$PID(job PID) or use the search mode of this Lexical
    it generally won't pick it up.
    
    Typically any system which has jobs entering MUTEX waits is probably
    mistuned, or maybe overloaded. The RWAST state can be caused by
    many problems, it would be helpful to know what image your process
    was running at the time. I used to get into this state on a cluster
    while running MAIL or NOTES (anytype) while SET HOST'ed in a cluster.
    If the image was written by you, sometimes mailboxes or altering of
    the process-perminate file logicals have caused this state. The
    telltale of this is, if you see several jobs in RWAST waits or other 
    strange states, it probably is System tuning or resource problems,
    if, however, you are the only one, it either something in your image
    or some 'undocumented' feature you've discovered. VAXWRK used to have
    a document named DEBUG or BUG that described how to track down the
    causes of these wait states. Also, there used to be a MACRO routine in the 
    VMSNOTES file that would go into the internal job control tables and
    kill the job, basically the routine when into the MUTEX queue list and 
    removed the job pointer from that table and then since the job was no 
    longer in a MUTEX executed a Process Kill System Service. The last time
    I ran it, (upgraded to V4 Table formats) it crashed the system, 
    this did STOP the process, but with some overkill :-) I haven't had a 
    chance to debug the problem, though I haven't checked VMSNOTES, maybe 
    someone has resubmitted a new version.
    
    Anyway, the best thing to do is notify your system manager, who
    should use SDA on the active system to try and find out what caused
    it and fix it (if possible) or at least document it for SPR/Notes
    submission in case of a suspected bug. For more, get a copy of the
    DIGITAL VMS INTERNALS and DATA STRUCTURES book from Digital Press,
    it goes into this, or try looking in the Notes library on VAXWRK
    for that other document.
    
    If you think I can help, just send me mail,
    
    
    					regards,
    
    						Dave
    
    
       

re .13

    I am  currently tracking down a problem similar to this one. The culprit
    (I  think)  is  NETACP;  I  have  3 or 4 batch jobs collecting data from
    PRO350's  and  uVAXen on a regular basis, and after 2 or 3 days I notice
    that  NETACP  has  started  to  fault  on the order of 500-1500 a second
    (really gets the job done on a 750 :-). Eventually, the batch jobs grind
    to  a  halt,  sometimes  in  RWAST, other times in LEF. If I try to stop
    them,  they  go  right into RWAST forever. The crash dumps all show user
    PC's  pointing  to  a  SYS$OPEN  of the remote file. The kernel PC is at
    EXE$DASSGN+04B.  I  also noticed that NETACP kept right on faulting even
    after the batch jobs stopped getting time.

    I don't  know  if your problem is related, but it's worth a look.

    Harley

    re: .14	(time to correct some misinformation)
    
    RWAST is a catch-all resource wait for VMS.  There are many reasons
    why a process can be put into RWAST.  See VAXWRK:::VMSNOTES for
    a couple of replies detail most if not all of the reasons.  Two
    of the most common reasons are insufficent BYTLM and I/O cancellation
    or deassignment.  
    
    STOP/ID performs a SYS$DELPRC system service call for the specified
    PID/process name.  SYS$DELPRC sends a kernel mode AST to the target
    process to be deleted.
    
    But if a process is in RWAST, then it is waiting in kernel mode at
    IPL$_ASTDEL for the resource RSN$_ASTWAIT to be "freed".  All ASTs
    (even special kernel ASTs) are delivered to a process at IPL$_ASTDEL
    (AST DELivery) and the process is already at IPL$_ASTDEL, no software
    interrupts will be generated until IPL drops and no ASTs delivered.
    $GETJPI, $DELPRC, ... all work by delivering ASTs to a process.
    But ASTs dont't work so ...  BTW, a SUSPended process also blocks
    ASTs and that is why it also seems to not exist.

    You can get a process out of RWAST but it requires knowledge of VMS
    internals and even then you are more likely to crash your VAX then
    not.  
    
    matt

    RSN$_ASTWAIT is not a resource.  It just indicates that the process
    is waiting for an AST to be issued in the hope that some resource
    will be freed by that AST.  For example, when a QIO is issued, space
    is required from pool for the QIO.  If another QIO is requested
    before the first completes and the process does not have quota to
    allocate more pool space for the second QIO, the process is placed
    in RWAST state.  When the first QIO completes, an AST is issued
    for the process.  This AST releases the pool from the first QIO
    allowing the second QIO to proceed.  In summary, it's not really
    waiting for the AST itself, but for the resources which may be freed
    by the execution of an AST.
    
    RWAST (Resource Wait - AST) is actually an MWAIT (Mutex or
    miscellaneous wait state).  VMS V4 does a little more than previous
    versions in describing exactly what is being waited for.  Other
    resource wait conditions include MPB (modified page writer busy)
    and SWP (swap file space).
    
    tom_p

	If you are designing and debugging an application you can call
	$SETRWM to turn off resource waiting, i.e. the call to $QIO or
	whatever will return immediately with an "insufficient quota"
	status of some sort.

	Cheers,

	Ciaran.