[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] mv.NET and U2.NET
I suppose I should have mentioned that Inland uses a very heavily modified and enhanced version of SHIMS (Supply House Information Management System) for the heavy truck parts and service industry. Of course, any programs that I wrote for Inland belong to them, and I could not share them (I don't even have them). However, I do have 12 years experience and knowledge to offer. Charlie Noah On 08-09-2010 2:45 PM, Charlie Noah wrote: I want to let the group know that I am no longer with Inland Truck Parts. I am, however, still 100% committed to the Multivalue world, and I hope to be working again in MV very soon. Regards to all, Charlie Noah ___ 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
