Mark Landin <mark.landin@tdwilliamson.com> writes:

> More elegant, but less secure. Further, hijacking a session which has
> terminated abnormally may actually cause more damage than using the
> method you already have!
>
> I'm curious as to why management thinks this is "more acceptable" than
> doing it the way you are now?

While I feel happy with my solution there is a belief that by getting
inside the session and sending a stream of strings representing the F3
key we can get the application to exit normally (F3 being our default
exit signal) but of course there is the element of what term type the
client was using (typically a vt220 but this too is a potential issue).
The original idea (not mine) was to enhance the client to time out,
send a series of F3's then disconnect, The problem is that there is no
guarantee that an F3 will actually effect an exit as some of the
screens are expecting an F12 to cancel and in any case disconnecting
without knowing if the session really terminated will doubtless lead
to more abandoned sessions and possibly problems with the database is
the application is in a critical section (my method checks to see if
the Informix sessions are in transaction or rollback, attempts to
wait those conditions out if they are found and opens a trouble
ticket without killing the processes if it is unable to safely
disconnect. _IF_ I could hijack the session I would have the options
of sending down a looping string of F3s and F12s for each of the term
types we use for a predetermined number of iterations, and if the
session were still active then it could be terminated by my original
method. To be honest I feel my original method is quite adequate but
there is that due diligence thing so I'm asking here. If nothing else
at least I'll be able to say that I checked with my peers and there
was a consensus that my approach is valid and somewhat safer.

Thanks for any and all feedback,
Chuck

--
-----------------------------------------------------------------------
|Chuck Mattern | "People often find it easier to be a result |
|camattern@acm.org | of the past than a cause of the future." |
-----------------------------------------------------------------------