This has happened to me in the past before the more current releases of MacPerl. What usually is happening is that your program only has X number of seconds to respond to the server before the channel is closed by the server. When the channel closes, the AppleScript hangs because it is still trying to respond to a server which no longer cares (ie: You've gotten the "No Data" message or some such by that time). What I used to do to correct the problem was to put in the &MacPerl::Quit(2) command. I did this because sometimes MacPerl would not close all of it's buffers and this too would cause a hang on the part of the scripts. (But the buffer problem was solved long ago by MN and no longer happens as far as I can tell.) Still, using the QUIT command ensures that MacPerl closes everything out and flushes it's output buffers. Yes, it takes a couple of seconds for MacPerl to load each time, but when you are trying to figure out where a program is hanging up your responses to people it makes debugging a lot easier. As I wrote to someone else just a few minutes ago, the easiest method to find the problem area is to simply divide the program in half with the QUIT command and to create a simple subroutine which can be called that just sends back a message that the program is quitting. The message will show up as the new web page or not depending upon whether you are before or after the area which is causing the problem. In only four or five trys you can usually pin point where the problem area is. For myself, this usually came down to either a FOR variable being reset somewhere (causing an endless loop) or a set of routines which kept calling themselves over and over endlessly. But for whatever reason it is, the above is the simplist way to track down the problem. For most programs, if the programs seem to work easily without going through the server but they hang when run through the server, it is a timeout problem. This means that your only recourse is to either break up the program into smaller chunks, or to change over to a compilable language like C for this particular routine. Chris (who wrote Quid Pro Quo) included source code examples of how to talk to a C program via QPQ. You can use that to re-write your Perl code so it runs faster. Or, you might want to just re-think how you are using Perl. Many times there are faster, easier, less time consuming ways to do the same thing that you are doing now. Anyway, just some insights into this. :-) ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch