Re: [U2] Sending interrupt to UniBasic program
Thanks to the suggestions from various posters, I have determined that my incriminations of screen were malicious libel. It's not screen. The issue of not being able to send an interrupt (e.g. kill -2/SIGINT) is a result of how I had to work around something in the third-party code I'm trying to automate. There are a couple input prompts, e.g. do you want to continue? y/n that I originally tried to handle with DATA statements. But the 3rd party software is doing something to clear the input stack. I've tried a few different workarounds, including hacking the CLEARINPUT verb, with no success. I finally got it work by doing a PCPERFORM as follows: PCPERFORM 'echo PROGNAME\\nY\\n\\n\\n | udt' This works great except that a SIGINT issued to the newly spawned udt process has not effect. A straight kill works, but it actually kills the udt process which is precisely what I do *not* want to happen. Any creative thoughts on how to get a SIGINT to work? Maybe a different way of calling PROGNAME? Talking to the vendor about changing their code is a theoretical option, but involves $ and a good deal of time, so is not preferred. 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
Re: [U2] Sending interrupt to UniBasic program
Have you considered placing a wrapper around their program? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of bradley.sch...@usbank.com Sent: Monday, August 16, 2010 11:40 AM To: U2 Users List Subject: Re: [U2] Sending interrupt to UniBasic program Thanks to the suggestions from various posters, I have determined that my incriminations of screen were malicious libel. It's not screen. The issue of not being able to send an interrupt (e.g. kill -2/SIGINT) is a result of how I had to work around something in the third-party code I'm trying to automate. There are a couple input prompts, e.g. do you want to continue? y/n that I originally tried to handle with DATA statements. But the 3rd party software is doing something to clear the input stack. I've tried a few different workarounds, including hacking the CLEARINPUT verb, with no success. I finally got it work by doing a PCPERFORM as follows: PCPERFORM 'echo PROGNAME\\nY\\n\\n\\n | udt' This works great except that a SIGINT issued to the newly spawned udt process has not effect. A straight kill works, but it actually kills the udt process which is precisely what I do *not* want to happen. Any creative thoughts on how to get a SIGINT to work? Maybe a different way of calling PROGNAME? Talking to the vendor about changing their code is a theoretical option, but involves $ and a good deal of time, so is not preferred. 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
Re: [U2] Sending interrupt to UniBasic program
Brad: How are you running the input prompt? I had an unusual problem with UDT when I wanted to get some PORT.STATUS information on a port running a phantom. This phantom process (an application background process) did a sleep 60 then tested for the existence of a process record; this went on in a perpetual loop. When I tried to find out if a port was running this process I had to do a PORT.STATUS on the port, but it didn't work because of signaling problems. The solution for me was to modify the code running the background program to loop for 60 then do a sleep 1. This accomplished the same thing but allowed for the PORT.STATUS to work properly. Maybe this is the same kind of problem you're having. Bill bradley.sch...@usbank.com said the following on 8/16/2010 8:39 AM: Thanks to the suggestions from various posters, I have determined that my incriminations of screen were malicious libel. It's not screen. The issue of not being able to send an interrupt (e.g. kill -2/SIGINT) is a result of how I had to work around something in the third-party code I'm trying to automate. There are a couple input prompts, e.g. do you want to continue? y/n that I originally tried to handle with DATA statements. But the 3rd party software is doing something to clear the input stack. I've tried a few different workarounds, including hacking the CLEARINPUT verb, with no success. I finally got it work by doing a PCPERFORM as follows: PCPERFORM 'echo PROGNAME\\nY\\n\\n\\n | udt' This works great except that a SIGINT issued to the newly spawned udt process has not effect. A straight kill works, but it actually kills the udt process which is precisely what I do *not* want to happen. Any creative thoughts on how to get a SIGINT to work? Maybe a different way of calling PROGNAME? Talking to the vendor about changing their code is a theoretical option, but involves $ and a good deal of time, so is not preferred. TIA, Brad. U.S. BANCORP made the following annotations ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Sending interrupt to UniBasic program
If you want to script some process, passing it input as though a real user were typing, expect is a good tool to use. http://www.nist.gov/mel/msid/expect.cfm I'm not sure if it will help your sigint problem, but it should be immune to the CLEARINPUT verb... Ian McGowan 925.609.2554 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of bradley.sch...@usbank.com Sent: Monday, August 16, 2010 8:40 AM To: U2 Users List Subject: Re: [U2] Sending interrupt to UniBasic program Thanks to the suggestions from various posters, I have determined that my incriminations of screen were malicious libel. It's not screen. The issue of not being able to send an interrupt (e.g. kill -2/SIGINT) is a result of how I had to work around something in the third-party code I'm trying to automate. There are a couple input prompts, e.g. do you want to continue? y/n that I originally tried to handle with DATA statements. But the 3rd party software is doing something to clear the input stack. I've tried a few different workarounds, including hacking the CLEARINPUT verb, with no success. I finally got it work by doing a PCPERFORM as follows: PCPERFORM 'echo PROGNAME\\nY\\n\\n\\n | udt' This works great except that a SIGINT issued to the newly spawned udt process has not effect. A straight kill works, but it actually kills the udt process which is precisely what I do *not* want to happen. Any creative thoughts on how to get a SIGINT to work? Maybe a different way of calling PROGNAME? Talking to the vendor about changing their code is a theoretical option, but involves $ and a good deal of time, so is not preferred. 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 IMPORTANT NOTICE: This message is intended only for the addressee and may contain confidential, privileged information. If you are not the intended recipient, you may not use, copy or disclose any information contained in the message. If you have received this message in error, please notify the sender by reply e-mail and delete the message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Sending interrupt to UniBasic program
Would you be able to remotely detach a screen session and reattach it for debugging? Assuming you don't know the user's password and sudo is available. At your terminal, 1. Find screen socket for user blahblah. sudo -u blahblah screen -ls 2. Detach the screen session sudo -u blahblah screen -d socket 3. Attach that detached session sudo -u blahblah screen -r socket You have to use your keyboard to debug UniData program anyway... so just take over a screen session from a user. :) -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
Re: [U2] Sending interrupt to UniBasic program
Thanks for all the input. Some of the idea look promising. I've got some research to do. 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] 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
Re: [U2] Sending interrupt to UniBasic program
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
Re: [U2] Sending interrupt to UniBasic program
Hi Bradley, We run everything under screen, batch processes (like you describe) and interactive terminal sessions. We dont have the problems that you are describing, and can break whenever we need to. But we are using UV and that may be better at handling break then udt. How are you invoking screen? Presumably in your batch process you do a screen -d -m udt progrname? You can specify a shell that screen invokes on start up - I havent used it myself but remember reading about it in the screen man pages and thinking it might be useful You can also type 'break' at the screen command prompt, but if ctrl-c isnt going to the right process then I doubt if the break command will. At the end of the day break is a signal sent to the process. You can always use a kill command (kill -2 i think) to force it to break. cheers, asvin bradley.sch...@usbank.com Sent by: u2-users-boun...@listserver.u2ug.org Aug 10 2010 16:52 Mail Size: 9075 Please respond to U2 Users List u2-users@listserver.u2ug.org To u2-users@listserver.u2ug.org cc Subject [U2] Sending interrupt to UniBasic program Entity Investment Banking Europe - IBEU 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 HSBC Bank plc may be solicited in the course of its placement efforts for a new issue, by investment
Re: [U2] Sending interrupt to UniBasic program
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 bradley.sch...@usbank.com 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 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
Re: [U2] Sending interrupt to UniBasic program
I've never run into the need to run a batch interactively, but for 1-time commands that take a long time to run, I use vncserver. It will run on AIX: http://www.ee.pw.edu.pl/~pileckip/aix/vnc_setup.htm I use RealVNC for Windows on the client end: http://www.realvnc.com/ But you can use any VNC client you want. Vncserver will run an X desktop that maintains its state regardless of client connections, so you can disconnect and reconnect anytime from any client. Once you're connected to the X desktop, you can open as many terminal sessions as needed. On unix and linux servers you can also run as many individual X desktops as you want, and run them as any user, eg: the connection myserver:0 may run as one user and myserver:1 as another. -John -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 8:50 AM To: u2-users@listserver.u2ug.org Subject: [U2] Sending interrupt to UniBasic program [snip] 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. [snip] ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Sending interrupt to UniBasic program
On 10/08/10 17:48, asvin.datt...@hsbcib.com wrote: Hi Bradley, We run everything under screen, batch processes (like you describe) and interactive terminal sessions. We dont have the problems that you are describing, and can break whenever we need to. But we are using UV and that may be better at handling break then udt. I don't think that's got anything to do with it ... I remember using wIntegrate and typing ctrl-c would be intercepted by it. So it was wIntegrate that died, not the UV program I was trying to interrupt (so of course uv died with it :-). How are you invoking screen? Presumably in your batch process you do a screen -d -m udt progrname? You can specify a shell that screen invokes on start up - I havent used it myself but remember reading about it in the screen man pages and thinking it might be useful This is where I think the problem lies. Unless you've done a chain, in which case udt is the shell, you've got a shell between AIX and udt, or screen and udt. I'm guessing it is this that is intercepting the ctrl-c and killing udt. How do you start UD? Do you log in and then say ud or whatever at the shell? Or do you log in and it just starts? If so, how? And when you quit UD, does it log you out or dump you back at the shell? If you don't already, take the shell out of the equation by starting ud with exec ud rather than just ud. Then logging out will kill your session, not just dump you back in the shell. If ctrl-c *still* kills UD, you then know it's something to do with screen. If things work as you want, you know it was something to do with the shell. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Sending interrupt to UniBasic program
UDT now has the tandem verb. It doesn't work as nicely as D3 but it does work. So, if the process is stopped you should be able to tandem to the port and see what's happening. HTH, Bill Wols Lists said the following on 8/10/2010 2:05 PM: On 10/08/10 17:48, asvin.datt...@hsbcib.com wrote: Hi Bradley, We run everything under screen, batch processes (like you describe) and interactive terminal sessions. We dont have the problems that you are describing, and can break whenever we need to. But we are using UV and that may be better at handling break then udt. I don't think that's got anything to do with it ... I remember using wIntegrate and typingctrl-c would be intercepted by it. So it was wIntegrate that died, not the UV program I was trying to interrupt (so of course uv died with it :-). How are you invoking screen? Presumably in your batch process you do a screen -d -m udtprogrname? You can specify a shell that screen invokes on start up - I havent used it myself but remember reading about it in the screen man pages and thinking it might be useful This is where I think the problem lies. Unless you've done a chain, in which case udt is the shell, you've got a shell between AIX and udt, or screen and udt. I'm guessing it is this that is intercepting the ctrl-c and killing udt. How do you start UD? Do you log in and then say ud or whatever at the shell? Or do you log in and it just starts? If so, how? And when you quit UD, does it log you out or dump you back at the shell? If you don't already, take the shell out of the equation by starting ud with exec ud rather than just ud. Then logging out will kill your session, not just dump you back in the shell. If ctrl-c *still* kills UD, you then know it's something to do with screen. If things work as you want, you know it was something to do with the shell. Cheers, Wol ___ 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
Re: [U2] Sending interrupt to UniBasic program
Brad, I'm not familiar with UD, but in UV it is possible to change the break key (character). Try changing the break char from ctrl-c to something else to see if the ctrl-c then gets passed to the PROG1 program. Gregor -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of bradley.sch...@usbank.com Sent: Wednesday, 11 August 2010 1: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 -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1AsWsnCEGR/7usjQpChsH1mcrVjkxlz5x/0 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
