Re: ftp get from vms fails with "file currently locked"

[Elian]

1 - No, not really, short of changing the FTP server. VMS has mandatory file locking, so the only way you could get the file is to have the server open it in read-regardless mode. You might check the FTP server's documentation--it's possible you'll get lucky.

2 - Net::FTP subclasses Net::Cmd. Try the message and code methods and see if they give you anything useful.

3 - Have the job create a flag file on completion, and check for its existence. If it doesn't exist, the job's not done. Or just have the job e-mail its files to you, which is pretty simple. Or have the job FTP the file to you--perl and Net::FTP work fine on VMS. :)

[mgibian]

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.

[waswas-fng]

It may be useful to put in further code that alerts you after X minutes when the lock has not been released -- because you are counting on another app to release the lock you could deadlock.

-Waswas

[mgibian]

The normal duration of the batch job on my VMS VAX platform is > 1.5 hours, and it can legitimately be significantly longer than that. So, while I do appreciate your observation regarding deadlocks, I think ignoring it for this particular application is acceptable, at least for the time being. I can always revisit the issue should it actually occur.