Good day -

With current situations as they are, we have a large percentage of users now working from home, as i am sure is common with most vendors. As a result, we are finding users are not fully logging out of the application... sometimes jobs are active for days. These chew up resources, licenses, etc.

So, how about an idea to have a global timeout option that can be activated in miame.ini that INFLD, XTREE can use w/o having to code for this individually in each field, program? I dislike the on-screen timer in INFLD... we use it on our login but that's it... so it would be silent. So what to do after a timeout is triggered? I'm glad you asked... An option would be added to tell ashell what to execute.. either via a cmd or run program.

Ie: GLOBAL TIMEOUT=3600:MENU.RUN

In above example, after 3600 seconds of inactivity the application will chain to MENU.

It could even be TIMEOUT.CMD which then could

:R
RUN MENU

YES i could add a timeout to every INFLD call and recompile all the apps... but what about all the XTREES? Seems this would be an easy global solution...

Something to consider in between super bowl commercials...

Frank - are you talking about IATIMEOUT? Did you RTFM?

Frank - No of course not... but now that I have, i am still unclear how this function works... is it set in MIAME? Do i check for error 254 and process that manually?

Frank - Not sure but either way you will need to do a full recompile and deployment.

Frank - Well $%^&.

Let's start with the MIAME.INI IATIMEOUT directive ... while I'm thrilled to see you RTFMing, I'm saddened to discover that the topic fails to mention that the inactivity timeout generates BASIC error 254. Also, it would be nice if there was a See Also reference to the related AG_IATIMEOUT command. Ty - can you please remedy that?

As for handling the error, basically you just want to shut down cleanly - which might already be the case. (Presumably you are doing something like this for other errors 250+?)

One problem with the server-side IATIMEOUT is that GUI applications may spend a lot of time on the client side, during which time they might appear to be inactive from the server's perspective. For example, one could spend a lot of time in an XTEXT or XTREE session without ever returning to the application. It would seem pretty rude to abort such a session. So for GUI applications, it might be better to set the server-side IATIMEOUT quite high (several hours?) but the client-side (AG_IATIMEOUT) at something much shorter (maybe 30 minutes?) To set the client-side timeout, you have to actually send the command at run-time, but you can do that in your startup menu. Also note that the client-side timeout counts mouse movement (at least within the ATE window) as activity, which prevents another category of unwanted timeouts. When the client side times out, it disconnects, so it shows up on the server side the same as any other kind of disconnect (generating error 250).

Thanks for the reply Cap -

Just to reiterate, a server side timeout registers as error 254 and client (ATE) timeout is 250? We do trap for 250+ , but i was hoping to trap the timeout and just take the user to the main menu where they could get back to work later. The menu has a built in 60 min timeout w/warning which will then logoff the user. I could trap the 254 and take them back to main menu but 250 is going to take them out straight away... which is better than staying logged in for days.

I'll have a play. Thanks.

I think you have it described correctly, at least in theory. Error 250 (disconnect) is essentially unrecoverable - other than that you can continue to run in background as long as no user input is required. But error 254 should be recoverable. In theory. But you'd want to make sure the timeout was long enough that it wouldn't be likely to trip up users who were actually studying some XTREE data without generating application activity.

Agreed. So if the user was in INFLD sitting for days... would i get a 250 or 254? Since in theory its a client side control i might expect a 250... i just wonder when i would ever get a 254 since in reality even an EVENTWAIT is a client side event??

You would get whichever one timed out first. If the user was sitting in a GUI prompt or eventwait, with no mouse or kbd activity, then both the server and client timers would be running identically. Since you would have presumably set the client timer shorter than the server timer, you'd get a disconnect (250). But if the user was sitting at that prompt doing nothing in your application, but moving the mouse around (sometimes across the ATE window) while working on other PC apps, that would appear like activity to the client-side timer, but not the server side, So potentially the server would time out first.

As a practical matter, you don't really want that kind of timeout (server side) because the server may not be easily able to unwind the situation (possibly leaving the user confused thinking the app is running because the GUI is still up, but maybe the server side is no longer.) That's why you probably want to set the client timer much shorter than the server side, for example, 30 minutes on the client, 4 hours on the server.

If a client timeout occurs or ATE disconnect, the server should get a disconnect 250. Then what is the need for a server side timeout at all?

I am doing some research this morning and here is what i have found.. quite insteresting:

Setting the server side timeout using miamex,180

I have found that in every instance of my ATE/Client side that i am getting a timeout error 254 in each of these active objects:

INFLD
XTREE
XTEXT
EVENTWAIT

So i am wondering the opposite of Steve - why use the client side timeout?

PS: Our trap routine will intercept any errors >=250 and process a user logout and end the ATE session. So perhaps that is why its working in this case? Either way it does seem that the server side timeout is sensing the fact that there is no activity on the client side and sending a 254 to the error handler.

PSS: Another interesting point, the client side timeout generates a sighup (250). It does the job of closing the session, however if we had to research an issue, we would have no way of knowing the source of the 250.. whether it was requested by the user or something else nefarious.

SO i am wondering, if the GUI controls will indeed report a 254 after inactivity, what would be the "con" arguement of just activating the server side timeout? TIA

It may just be a matter of preference or perspective. The side that initiates the disconnect has the best experience. As an analogy, consider a cell phone conversation between you (the client) and your therapist. Each of you inactivity timer app that buzzes when it times out, but the behavior is slightly different. On your side, when it times out, it disconnects. So if you put the phone down to cry and then here the buzzer, you know that you just hung up on your therapist. But on his side, the buzzer is just a warning. But if you put down the phone to cry, he's not going to be able to get your attention, so he transfers you back to the receptionist and takes another call. Eventually you stop crying and try to resume telling him about your painful high school experiences, only to discover you're now talking to an auto-attendant. Very irritating, particularly since you don't even realize why.

Since the client (you) has human feelings, where as the server (your app) doesn't, one school of thought would be to favor the client, which in this case I think means relying on it as the primary inactivity timeout.

But, since the client side timeout isn't foolproof (consider an unplanned reboot), and because the server might accept non-GUI connections for special purposes, it's good to have a fall-back timeout on the server side (but again, probably much longer than the client-side).

Yah but if all i did is put the phone down to cry, and the therapist thinks i hung up on him then we now have a miscommunication and he won't take my call anymore...

IF the client side timeout issued a 254 as did the server side (And i might just take the opportunity to argue that it SHOULD) then it would be a no brainer, but i am not sure i can trust a bunch of sighups in the log just due to inactivity...

You have eloquently left the programmer to cause the damage here... ill figure out what's the best way forward for us.

Thanks.

PS: Does MIAMEX, 180 work on windows servers?

What's MIAMEX 180. Oh, you mean MX_IATIMEOUT It's a good thing you didn't go into fashion design, or we'd all be wearing numbered outfits.

Yes, it works on both Windows and Linux.

On a side note, although the server can send AG_DISCONNECT to the client, it won't be understood if client is in the middle of a client-side GUI call. (ATE commands are synchronous.) So there's no good way for the server to explicitly tell the client that it is hanging up in a way that will be immediately recognized.

Ok thanks.

Hypothetically, if i set the server side timeout to something like 8 hrs, there should be no way that that session is still active. (i.e. being serviced by a human being). I have tested the timeout with all of the above gui controls having focus and after a few seconds it will issue a disconnect message to the screen. The only thing i like better from the client side timeout is it just kills the session and poof its gone. In the case of miamex "180", you get the client disconnect dialog, which maybe isnt a terrible thing.

Perhaps I should look into why the client-side timeout doesn't respect the option to display the little message box on close (Connection Properties > Misc > Close on Disconnect).

Also, I should point out that although you can trap error 254 (just like you can 250), there's isn't much you can do beyond logging information to disk. As soon as the process goes into a keyboard wait state, it gets shut down. (Otherwise the point would become moot, unless the application specifically dealt with that error.) I suppose if we wanted to get fancier, we could add another MIAMEX function to clear and reset the IATIMEOUT after responding to the error?

Hey Cap - a couple thoughts on above:

1 - The client side timeout very well may be working... as i said ours just closes and exits w/o any user warning. This is by design for us... so not sure there is a problem there.

2 - As far as registering 254 i agree with all your points, however the importance of seeing 254 in the error log is better than seeing a 250. With that being said i wouldn't push out an update for this change so its up to you if you want to implement it. I have decided to stay with the server side timeout alone. It's doing everything we need so i don't see the benefit of setting 2 timeouts.

In the beat a dead horse genre.. i have been testing the timeout. Set it to 8 hrs on the server side and it didnt actually generate a 254 code until about 16 hours! So then i started with some smaller tests, both client and server timeouts seem to be all over the place. Of course YMMV but keep this in mind when setting yours.



I didn't extrapolate it all the way out to 8 hrs (480 min) but by 3 minutes we can see the actual timeout is almost double!

I have a distinct memory of having written somewhere that because of massive uncertainties in the way these timers work, the actual timeout is likely to be up to twice as long as the amount specified. But I can't find that note now. Perhaps Ty can add it.

Thanks Cap - I also recall something to that nature.... but i couldn't find it either.

I'm gonna go with the mean of the standard deviation * 2

Did an hour test and it timed out almost exactly 2 hours later. But Ty, i think i have figured it out... it's like startfleet code... seconds=minutes. minutes=hours. hours=days

(only trekkies will get that one )