Conference iosg::all-in-1_v30

    Bill,
    
    I know of no TIMEOUT Function.  There are some other possibilities
    depending upon the interface where the user enters the password.
    (What is ATM?)  Can you pass the password to the interface?  Could
    this be done via script, arg form, etc. with the exit or bye function.
    
    Again depending on the interace you can write your own code to
    do this using the INSTALL and EXECUTE functions or write a
    Site Defined Function (SDF).
    
    
    Tim

Or as a hack, use the DCL command READ/TIMEOUT=nnn to request the information
from the user, but you would have to be careful about screen handling etc.

mb

    Sorry Tim, ATM stands for Automated Teller Machine. The reason I
    compare the application to an ATM is as follows :- the user enters a
    password on an ARG form, which is verified against a file. Once verified
    the user is allowed access to a menu form containing options for
    different information. When the user completes his/her transaction the
    application returns to the 'password' form. The timeout is to ensure
    that if the user walks away from the terminal without completing the
    transaction the application still returns to the password form.
    
    
    I had considered writing an SDF which would create a mailbox and queue an
    asynchronous read on it. Commands could be written to the mailbox by a
    monitoring process when it found the ALL-IN-1 session inactive which
    would subsquently be despatched. I'm hoping there's an easier way
    though.
    
    Bill. 
    
     
    
     

        Bill,
    
          I have written a BASIC program that does something similar to
        what you have described. The program set up a Mailbox, set an
        asynchronous flag and waited for a read on the Mailbox. Once the
        flag had been triggered, the asynchronous portion took over and
        Re-entered the ALL-IN-1 process to display an index form.
        (Before all the ALL-IN-1 guru's loose their minds, the application
        didn't just arbitrarily call the index form, there was a lot of
        checking to see it it was an appropriate time to call the index
        form).
    
          Now for the bad news...As soon as I had got the application to
        work, I got word from engineering that asynchronous processing, in
        the manner which I was doing, was not a good idea...I thing the
        exact quote was .... DON'T DO IT!!!!!!!!!!! I can't remember if
        the reason was because I was Re-entering the ALL-IN-1 process, or
        if asynchronous processing in it's self is a bad idea from
        ALL-IN-1. (any engineers want to let us know why?) In any event,
        I'll be glad to pass along the code I wrote for you to look at.
        Contact me off-line.
    
        Regards,
    
        Mike
    

    Did you discuss your idea here (or in one of the previous versions)?
    
    I wonder who in engineering told you it was a bad idea. Perhaps you
    could mail me their name and I'll ask them. Did they say why it was a
    bad idea?
    
    Graham
    
    PS You'll be depressed to know that we had this as a requirement for
    V3.0, but it fell off the end of the list of things we had time to do...

    
    	Its a fair cop! I seem to remember the discussion a while
    	back. If I remember correctly, a script called the SDF
    	which set up an AST and returned. At some time later, the
    	SDF "wrenched" control back from the main image when its
    	AST fired, and it then reentered the image at AST level
    	by trying to execute script commands. Clearly this is a bad
    	idea (you can't predict what the main image was doing, it may
    	even have had privs turned on) and I'd still say don't do it,
    	but I'd be interested in what checks you built in to "see if
    	it was okay" to display the index form (I don't remember these
    	checks last time around, maybe you added them later).
    
    	GET OA$DCL='READ/TIMEOUT...' sounds good to me.
    
    Regards,
    Paul