Brad,

On UniData we use the @USER.TYPE to determine if it is a phantom / background 
process or not.   IF @USER.TYPE = 1 THEN  INPUT ELSE ...    Below is a snippet 
from the Unibasic manual.


@USER.TYPE Returns the type of process currently running. UniBasic has 
three types of processes:
0 - Normal terminal processes.
1 - Background (phantom) processes.
2 - Redirected standard input.

HTH
-Dan


-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of 
bradley.sch...@usbank.com
Sent: Tuesday, August 10, 2010 11:50 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Sending interrupt to UniBasic program

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
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to