Conference noted::hackers_v1

    
    What about the REQIDT argument of $SETIMR ?

    
   
    
    
    
    
   

    What you could do is use a rather transparent methos of passing
    parameters, but one that also WORKS (what a concept, eh?)  Try passing
    the parameters via a construct better know to FORTRAN programmers
    as a COMMON block?  Fill the variable in one subroutine, and whala
    when the AST is fired off, it finds the variable set.
    
    -- Nestor
    
    P.S.  Please don't take my first sentence negatively, I did not
    mean to imply that the other suggestions would not work, just that the
    solution I proposed has in the past done the trick for me.
    
    

    	I use REQIDT as the address of a context block, and assign the
    context block from dynamic storage when I need one.
    
    	Since the address of the block is particular to the request, there
    is no problem of duplication, and the block can contain anything the
    AST needs to know to do its job.

	RE .0
    
    	Sorry about the name of this topic - my fingers have habits
    	I don't know about. Mr. Moderator, a great title would be
    	"$SETIMR AST Parameter"
    
    	RE .1
    
    	... this is an image, not a command procedure (BLISS, actually).
    	Thanks, though.
    
    	RE .2
    
    	... You would have to explain how I could have more than one
        request at once. I can have multiple timer requests outstanding
        to the same AST. I cannot see you're way working. 
                                                          
    	RE .3
    
    	... oh. I thought the request ID was an output parameter to
    	SETIMR. Apparently, it is an input. This may work.
    
    	However, it also identifies the timer request to the system.
    	If the same parameter is passed to two timer requests
    	simultaneously,	than I cannot cancel one without cancelling
    	the other. This would be inpossible to live with.
    
    	It looks like I'll have to set up a separate data structure
    	for each request - a timer request block -- TRB, and pass that
    	as the timer request ID. Then, the AST receives this address
    	as a param, and can look into it to find the _real_ parameter
    	I was trying to pass. Allocate, do a SETIMR, then deallocate
    	the TRB. 
    
    	... could work. However, sounds too much like "management" to
    	me (yech!). If all else fails, I suppose ....
    
    	Keep the responses coming!!!
    
    	kevin

>        	                    Mr. Moderator, a great title would be
>    	"$SETIMR AST Parameter"
    
    	Mr Mendel, Try NOTES>SET NOTE/TIT="$SETIMR AST Parameter" 626.0
    
    
.2>	Using a common that the timer ast knows restricts you to one
    	outstanding time at a time. It also offers a maintenance nightmare.
    
>        	... oh. I thought the request ID was an output parameter to
>    	SETIMR. Apparently, it is an input. This may work.
    
    	It *will* work. Half of the system relies on it.
>    
>        	It looks like I'll have to set up a separate data structure
>    	for each request - a timer request block -- TRB, and pass that
>    	as the timer request ID. Then, the AST receives this address
>    	as a param, and can look into it to find the _real_ parameter
>    	I was trying to pass. 
    
    	Right. That, or you can simply pass a pointer to (the address
    of) an existing datastructure as argument. The address will serve
    as unique ID for any cancel, the contents will serve as argument
    once the AST fires.
    
    
>    Allocate, do a SETIMR, then deallocate the TRB. 

    	Wrong. Better wait for the timer to fire or cancel the
	timer before you deallocte such a TRB. Again: you can pass
    	the pointer to an existing, more or less static, data-
    	structure instead of copying the info into such dynamic
    	memory. Note: 'data-structure' can ofcourse be anything
    	ranging from a bit through a long through a record..

>        	... could work. However, sounds too much like "management" to
>    	me (yech!). If all else fails, I suppose ....
    
    	You'll find the *thinking* about it will be the only effort
    	required. once you understand the problem, you will notice that
    	the actual implementation requires NO code, just careful
    	passing of arguments.
    
    Hope this helps,
                    Hein.
    
    Hein.
    

    -- Hmmm. I didn't think I had the privs, but a true hacker would
    have checked first. The title is updated.
    
    -- I know _SETIMR_ works .... what I meant was the method would
    might make my program work. 
    
    -- Well, I _meant_ deallocate the block AFTER the timer expires,
    unless it gets re-requested. (Geez!)
    
    -- I don't want to pass the actual parameter as the RQID, because
    the same data block might be passed to several timer ASTs, and that
    would make cancelling a particular request (almost?) impossible.
                                        
    Thanks for your help, everyone! I'm gonna go with the allocated
    request block mechanism, instead of using RQID to pass the actual
    parameter. One block for each request. I can put in other handy
    things in the block, like whether the request gets re-submitted,
    how many times it gets re-submitted, the number of seconds in the 
    timer interval, etc. Also P1, P2, P3, and P4 parameters, and a 
    subroutine address. 
    
    Instead of separate AST addresses, I'll have just one for all $SETIMR
    requests. I can pass the name of the subroutine I _really_ am after
    in the request block. This main AST routine  can re-submit or de-allocate
    the request block, and call the the request subroutine, passing
    up to four parameters. Get it?
    
    Work, Work, Work ...
    
                                                

A few simple hints using $SETIMR (since I haven't read all the previous
replies, some of it may be redundant):

1. The REQIDT argument is used BOTH for AST parameter and indentifying
   the timer for cancellation (which doesn't seem like the best thing).
   If you need BOTH functionalities, you may consider some alogirtihm
   for using it properly (I have one in case anyone is interested).

2. The AST parameter is "saved" upon calling the $SETIMR, so if it is
   some variable address (passed by reference), you shouldn't change
   its value later. If, however, it is passed by value, you should be
   prepared to receive it this way in the AST (e.g., use Fortran's
   %LOC function).

3. The $CANTIM service works, but if you use it from within an AST, you
   should consider the possibility that the timer has already expired
   and its AST has been queued, waiting for the current AST to return
   (and nothing is cancelled). In such cases, some application
   synchronization is needed (via some common variables etc.)

/Nitsan

Another thing to consider in applications that use a lot of $SETIMR/$CANTIM
calls:  $CANTIM is a surprisingly expensive operation.  It's often easy to
tell that you don't need to cancel a timer, even though the simplest code may
not have this information and may just cancel "to be sure".

...not that you'd notice the difference in most applications.

							-- Jerry