Hi Bradley,
Instead of having the operators directly interact with the product, set them up
to indirectly interact. Put a check for "direct interaction command" into the
main loop. Just create a file that the process checks every iteration to see
if there's a 'direct interaction' request in the file. Have the program
perform that interaction and then return the results the same way. This turns
the process into one that can be run as a phantom and still meet all the
requirements.
Or just leave it running in SCREEN and then have it check the file for a BREAK
command.
READV BREAK.NOW FROM OPER.INTERACTION.FILE, 'DIRECT.COMMANDS', 1 THEN
IF BREAK.NOW THEN
WRITEV '' ON OPER.INTERACTION.FILE, 'DIRECT.COMMANDS', 1
DEBUG
END
END
If you have multiple loops constructs inside the program, you may need to make
the BREAK logic a subroutine that gets called from somewhere within those
constructs and code even have them set another flag such as "WHERE.FROM" so
that after the DEBUG you could print the WHERE.FROM var and see that it came
from the XYZ subroutine.
Allen "Code Monkey" Elwood
---- [email protected] wrote:
=============
All,
I'm hoping the bit-heads in the group can help me out with this one. It's
kind of difficult to explain, but I'll try my best. My apologies for any
lack of clarity.
What we're trying to do is automate a third-party batch process. The
automation piece is working well. But there's one requirement that's
proving problematic, with two key requirements at play.
First, batch process must run automagically and completely unattended.
Second, operators must have the option to interact directly with the
automated batch for trouble-shooting purposes. The second requirement is
what's presenting the challenge.
Since we need to be able to directly interact with the batch process, we
can't use a phantom, since any keyboard I/O causes a phantom to terminate.
The solution we chose was to run everything under GNU Screen. If you
aren't familiar with Screen, here's a one sentence description from our
friends at GNU -- "Screen is a full-screen window manager that multiplexes
a physical terminal between several processes, typically interactive
shells." You can check http://www.gnu.org/software/screen for more info. I
think of Screen as a terminal emulator that runs locally on the server. So
if you start screen and then launch UniData from within your screen
session, you are safe if the connection from your workstation is dropped;
everything continues to run on the server. You just need to issue a
command to reconnect to your screen session and you're back in business.
Very handy tool.
If the batch runs with no issues, this works well. But if we need to
diagnose a run-time issue, e.g. a process appears to be hung, we need to
do things like send ctrl-c to break the current program. This is where the
problem comes in. Screen seems to be sending ctrl-c (or any other
interrupt, for that matter) to udt, not the program that is running under
udt. This causes the udt session to end which kills the batch process when
all we want to do is get to the debug prompt. Questions to the Screen
users group have not generated helpful answers.
Here's an attempt at an illustration of what I'm talking about. Nesting
indicates that a process is running under the outer process.
Non-Automated:
Can press ctrl-c while PROG1 is running to get to debug prompt
AIX
udt
PROG1
Automated:
Ctrl-c and AIX kill's are directed to udt, not PROG1
AIX
screen
udt
PROG1
Does anyone have any thoughts on how to resolve this? My hope is that
there's a way to send an interrupt from outside that will be directed
towards a specific program.
Environment info:
AIX 5.3
UniData 7.1
TIA,
Brad
U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains
information that is, or may be, covered by electronic communications privacy
laws, and is also confidential and proprietary in nature. If you are not the
intended recipient, please be advised that you are legally prohibited from
retaining, using, copying, distributing, or otherwise disclosing this
information in any manner. Instead, please reply to the sender that you have
received this communication in error, and then immediately delete it. Thank you
in advance for your cooperation.
---------------------------------------------------------------------
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
