Conference iosg::all-in-1_v30

    Hi there!
    
>but that's too easy, I am calling the script from an installed
>image (that is executed asynchronously just to make it more 
>complicated).
    
    	What do you mean? You INSTALL a dynamic function and then
    	use the ALL-IN-1 EXECUTE function to call it? How do you
    	mean "it is called asynchronously"? You don't mean that the
    	executed function somehow grabs control from the image and
    	merrily starts trying to execute a script? That's certainly
    	not allowed! (You don't expect us to write REENTRANT code
    	do you? :-)
    
    Regards,
    Paul

    I was afraid if I mentioned the "A" word, I would get my hand
    slapped. ;-) But, yes I have written a Basic program that sets
    up an AST and when satisfied, the asynchronous program does a
    callback to the ALL-IN-1 image. The Basic .EXE file is INSTALLED
    and is executed from ALL-IN-1 with the INSTALL/EXECUTE functions.
    This all works about 90%. I still have a few problems to work out
    with returning to the form that was interrupted, but everything
    else works, 'seemingly', fine.
    
    My problem is getting the Mail function to work correctly. I have
    had it working correctly at one time but I re-designed the system to
    meet customer requirements, so I know it can work.
    
    
    Still looking for answers to my Mail function problem.
    
    
    Paul, if asynchronous processing is not allowed could you
    mail me off-line and tell me why? When I first had the idea
    to use asynchronous processing, I asked around and could not
    find anyone who would say it couldn't be done, only that it
    hasn't been done. So I did it.
    
    Thanks,
    
    Mike

    As it always happens on the first MAIL call, and sometimes doesn't
    happen at all, try initialising mail before you EXECUTE your INSTALLed
    function. (All MAIL functions do an implicit MAIL INIT, which has no
    effect if it's already been done).
    
    I.e. put a MAIL INIT somewhere where it will always get executed before
    you get into your INSTALLed code - in the script where you call INSTALL
    might be a good place.
    
    Now, as to _why_ this happens . . .
    
    A guess:
    
    Do you have DDS turned on? (OA$DDS_PRIME = 1 or 2) - DDS does things
    with ASTs (lock manager blocking ASTs in particular) which can have
    weird effects (and MAIL INIT calls DDS INIT which sets up the ASTs).
    
    Dave.

    
    	I suspect my learn�d collegue has missed the point that you are
    	re-entering the image at AST level.
    
    	Why won't this work? Well, where do I start? There are HUNDREDS
    	of reasons this won't work, the most common result I would have
    	expected would be an ACCVIO. For starters, the ALL-IN-1 image
    	is just basically not reentrant. That means we use OWN data
    	all over the place. Consider the following code:
    
    	OWN foo_init = 0;
    
    	ROUTINE OA$FOO_INITIALISE()
    	    BEGIN
    	    IF .foo_init EQL 0
    	    THEN BEGIN
    	    foo_init = 1;
    	    .
    	    . do some processing
    	    .
    	    END
    
    	Now if we are in the middle of this "some processing" and your
    	AST fires, and you call a "foo" function, all the code will think
    	that ALL the initialisation has been done, when in fact it hasn't.
    	I would expect a liberal sprinkling of ACCVIO's to result.
    
    	You can't even read the value of a symbol reliably, as the main
    	processing may be just creating a new symbol and is just messing
    	with the pointers to the symbol tables. Again, ACCVIOs likely.
    
    	I suspect that your actual problem is that you are re-entering the
    	image at AST level, strictly a no-no. This has the effect of
    	disabling ASTs, so DDS probably won't work. The process is
    	probably waiting for an event flag that should be set by an AST
    	routine. The AST is queued to the process, but will never be
    	delivered because you are already at AST level. You could look at
    	the process from ANAL/SYS and see if any ASTs are active when the
    	process hangs (not that I am suggesting you should persue this any
    	further!)
    
    	In short, DON'T DO IT! It won't work reliably, if it works at all.
    
    	Now, back to your application. What you could do is still have your
    	AST, but DON'T reenter the image unexpectedly. Instead, just set
    	some variable in your image so you know you have been called, and
    	then return from the AST. Then in your main application you could
    	keep EXECUTEing a function in your image which checks the flag, and
    	if set, re-enters the image to send your mail message. You could
    	use the script symbiont and have a script that just does a loop:
    
    		INSTALL ....
    		EXECUTE MY_AST_SETUP
    	.LABEL LOOP
    		GET OA$DCL = "$ WAIT 00:01:00"
    		EXECUTE MY_TEST_FUNC
    		.GOTO LOOP
    
    	What is your application? Maybe we can dream up a different
    	approach.
    
    Regards,
    Paul

    
    	Your AST routine could also do a SND_JBC to submit a script to
    	the script symbiont (or to a VMS queue which runs up ALL-IN-1
    	and executes a script if you are still on V2.4).
    
    	This sounds to be close to what you want to do.
    
    Regards,
    Paul

    Derrr - thanks, Learned Colleague
    
    D.