Jim,

I believe I mentioned I'm on a Windows client. It's not a telnet timeout
issue; it's an auto-logoff-due-to-no-activity issue. So I just need a
windows app which will simply poke a character into my Universe process's
input buffer every so often. It would be nice if it would monitor process
activity and make sure it's not poking into an active session.

So far, the most relevant response has been the one suggesting the 'drinking
bird' solution (I actually have one of thoese things), but it needs to
actually drink water to keep the motion going.

Ed

"JJCSR" <JCronin (AT) ktp (DOT) com> wrote

Hi Ed,

If you're still looking, I recently came across AutoIt, a freeware
scripting utility for sending keystrokes and mouse actions in Windows.

Here's the URL: http://www.autoitscript.com/autoit3/

Jeff

Ed Sheehan wrote:

Thanks, Jeff. I'll check it out.

Ed

"Jeff" <jw.groups (AT) gmail (DOT) com> wrote

Ed Sheehan wrote:
Try Winbatch http://www.winbatch.com/
It should be fairly simple to write a background process that sends the
keystrokes needed.

Scripts and proggies are OK/easy, but the question is, what exactly
are you going to force to a user session that won't interfere with
someone who's actually working? Look at your keyboard. Ctrl and
Shift are harmless but don't activate a server session, so you need to
send a real character .. and then you need to backspace to get rid of
it. That could corrupt data entry. Sending a single keystroke when
the server is at "INPUT X,1" can send the user somewhere they don't
want to be.

All of these solutions are attempting to get around the real problem,
that Ed is trying to do system administration without being given
permission to do the job. Solve that problem and you won't need any
gizmos that might corrupt data. Find the "real" SysAdmin person and
tell them the command to set the inactivity timeout.

T

Inline...
"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

I'm the only user in this case. I'll be at TCL.

Look at your keyboard. Ctrl and
That's why I'd like to have the proggie check for inactivity for a time I
specify before sending, probably, a space, then backspace. Don't want to
blindly send something, as I might be testing.

I don't consider that me or my program typing a character or two as "doing
system administration." You might be able to say I'm attempting to
circumvent the intent of the SA by having a proggie do the typing for me,
but, since I'm a programmer, that shouldn't be a problem. I could set a
timer to remind me to do it, but why can't a program do the same thing?

Solve that problem and you won't need any
The timeout value is fine the way it is. The SA might be perfectly correct
to set it at one hour. But since I'm using FTP to save program files, which
don't activate the session, and I may well be in a program more than one
hour before I want to run a test, I need something to keep my process alive,
so I don't have to remember to ALT-TAB back to Universe to hit
space/backspace. A client program to do this does not violate the intent of
the timeout value IMO.

I would never condone a user doing this to artificially keep the session
alive. But my programming environment justifies a different approach, again
IMO.

Ed

"Ed Sheehan" wrote:

How does an external program know that? Are you expecting this
proggie to read the screen too, note that a specific character and
nothing else is in a given column, and from there it should decide to
send a ping?


That's the key to the problem. A script that writes to the handle of
an open window has no idea what the application is or what's on the
screen. It doesn't know if you're testing or even connected. The
tools mentioned have no awareness that you're using a terminal
emulator connected to a remote server.


Stated above, the program has no idea when your fingers are on the
keyboard or not, and random keystrokes can/will interfere with your
activity.


I think you need another approach, Ed. The DBMS timeout should be
doing its function. If you are using FTP or some other long operation
within that session then Universe should see the activity and not
consider it to be an unattended process. If it does then the timeout
function is broken and perhaps should be turned off. If you're saying
you're watching FTP or whatever on another process and you don't want
your terminal session to logoff on you, that's fine, but again a
proggie has no way to know what you're doing or what your intent is.

I'd suggest that while you're doing your development, just have the
timeout turned off. And definitely use the Accuterm KeepAlive
setting.

Why aren't these options viable? I'm not trying to lead in a specific
direction, but based on the information available to us I don't think
you have a viable solution yet. So let's get more information or more
solutions appropriate for the purpose.

Regards,
T

Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

It doesn't need to know anything. It would only run on my workstation. It
would only check a specific window (with the string, "Dynamic Connect" in
the title). It would keep an activity timer going. When no activity had
occurred in a given amount of time, it would send the characters to that
window's process. Very specific and low-risk IMO.

Are you expecting this
Column? Specific Character? No, just, "did the process activate?" Not sure
what you think I said here...

Not just any open window, but rather a window I specify. No other windows
would be in the monitoring queue unless I placed them there.

Not random, but only keystrokes I specify. The program would reset the timer
when keyboard activity is sensed. When no keyboard activity has occurred AND
no process activity (a program running, say), then it would send what I told
it to send, then reset the timer.

I'm using EditPlus for development. It uses FTP to update the program in the
file system. It doesn't activate any Universe process in the, uh, process of
saving my program. So I could be coding for a long time and lose my logon.

Not possible, politically. Fiefdoms and the like.

It seems (nearly) dead simple to me. I Hope I (re)explained it better this
time. Thanks for your insights.

Ed

"Ed Sheehan" wrote:

That's where this breaks down. Windows programs don't know what
"activity" is. A filesave streaming output is activity but another
program monitoring a terminal emulator has no idea that output is
streaming to the emulator. With a screen saver type program we can
tell if there is no keyboard IO for some amount of time, and get it to
do what you're talking about.

Now... I haven't thought about this but it may be possible to write a
script in Accuterm that will detect no input or output for some period
of time, and take action on timeout. However, it's still possible
that this script an you as a user will execute a keystroke at the
exact same time, and that will result in the sort of conflict you're
trying to avoid. Again the real solution is to handle this on the
server.


Again, "active" is relative to an application. In a terminal
emulator, the session is active if the 80x24 screen looks different
from one moment to another, or if keyboard input has been received.
That needs to be monitored by a program that understands that this is
an emulator - and Accuterm can do this, but an external program can't.



As above, to an external program one wHnd (Windows Handle) is just
like any other. You can get a handle (ID) for an given window, even a
process, but you can't tell what's going on with that process unless
you have some sort of application-specific API established. That's
why these external proggies are inadequate.


You can do that but this is a precarious solution that at some point
could fail. If you don't mind the occasional interruption to your
work when you and the timeout code decide to hit a key at exactly the
same time, then go for it.

The key poking programs suggested so far have no concept of a timeout,
more code needs to be wrapped around them. Even if they do, a
keyboard monitoring, key echoing type technology is an answer to the
problem but it's far from being the right solution given the
requirements.

Many solutions adopted by MV people (for email and Excel for example)
are only partial solutions, but people seem to live with them quite
comfortably. It's hard to argue when someone points to something like
this and they say "look, it works!" but it's obvious that there are
factors that will cause it to not work outside of the most basic test
case. I don't want to debate this with you too long - feel free to
try something and you'll soon see exactly what I'm talking about as
far as the limitations.


The price of someone else's fiefdom is that they will need to pay for
your grief as you need to constantly login in response to their
draconian timeout policies. That's the cost of doing business.


It is a simple problem but when people put roadblocks in the way of
real solutions then we need to come up with funky technology to get
around the roadblocks. I've explained the issues. If you find a
reasonable solution to the problem I'd be as interested as anyone to
hear how it works for you.

Regards,
T

Hi Tony,

I have to admit I had similar reservations when I posted a programmatic
'drinking bird' solution. I agree that any dumb bird -- or indeed any
dumb script -- will simply do its thing whenever it wants,
single-character pick prompts be damned. I cancelled my first post with
that in mind, wondering how annoyed poor Ed would be when his commands
were speckled with scripted guano.

Then I thought to myself, "we're all grown-ups here", and I went ahead
and answered Ed's original query. I figured the standard phrases "your
mileage my vary" and "caveat emptor" automatically applied. After all,
who was I to assume that Ed wouldn't work out these concerns on his own
with an elegant and attentive little Ruby script? It was free advice
but I probably should have mentioned my concerns.

Anyway, thanks for taking up the slack in my conscience.

Regards,
Jeff


Tony Gravagno wrote: