VERY helpful response, thank you.

1 - Rats... of course, if I logon to the VMS system, I can type the file, so I could Net::Telnet to type to another file if I really want to look in the file, I guess.

2 - The error code returned by VMS IS indeed returned by the code method. So, I've added logic to grab that and if its the file locked code, 550, then I sleep a bit and try again. The only negative is that I'm not showing any progress so it needs to be taken on faith that the batch job is actually moving forward and hasn't died. On the other hand, I'm pretty sure that if the job dies, then the lock is released and I can ftp the file and look in it for my desired results.

3 - All good ideas (though the e-mail one seems less useful in my specific context). My goal is a script that submits the VMS batch jobs, does all the work on the local Windows platform that can be overlapped, then goes to look at the logfile from the batch job to sync up with the VMS jobs. Since no more work can be done in parallel, I don't mind waiting for the file to unlock at this point. The script needs to block until the job is done, so the only negative is that I'm not seeing what is happening while I wait.

My ideal situation would be that when I end up waiting, I can display the output of a VMS "type logfile /cont/int=XX" until the job finishes, but that is probably more trouble than its worth.

Thanks again for your help.