Re: FTPing save files -- locks?

James H. H. Lampert wrote:

When downloading a save file by FTP, is there anything that
happens under the covers, that would cause the operating system
to briefly (but long enough to make a RSTOBJ on it time out) grab
a lock on the save file after FTP reports the transfer complete?

The final write and close of the save file should be synchronous to prevent any conflicts for activities later in the same [sub]command stream being performed serially. The /close/ includes the action of dropping the lock held for the open\read or open\write activity.

When was the save file created? What was the actual script of [FTP] activity, and was the failing request [apparently an error to open the save file due to inability to allocate] within the same script or submitted to run in another process?

Some HA feature(s) will /notice/ an F-CO for any *FILE object [by explicit CRTSAVF or by FTP GET of a .SAVF named file] and will attempt an asynchronous operation against the file. That action would normally effect a short-term *EXCL lock of the object; though I am not clear on support of ALCOBJ for a *FILE with the attribute of SAVF. If the CO [create object] audit record does not include the attribute of the *FILE or SAVF device files are included in the replication rules, then it should be expected that a lock may exist between object creation and activity against that object.

The common data management for a [save] file includes the /common/ "file wait" feature to enable the file open request to pend over allocation issues. The default on the WAITFILE parameter for the CRTSAVF command [and likely for the create done by FTP of an implicitly created savefile] is the special value *IMMED which means there is no waiting enabled for any conflict between open activity and other activity which would preclude open for allocation of the file resources. Whether the file is created by FTP rather than the script or prior to the scripted FTP subcommands, the OVRDBF can be used to establish the wait file time for an open performed by the RSTOBJ DEV(*SAVF) SAVF() in the same process.

FWiW I recall there was a defect at one time [maybe still] with FTP adding records to a save file which is open in another job [any open precludes most if not all I/O for the same save file]. Except to investigate if\what error, having a save file open with DSPSAVF should be avoided in conjunction with use of either PUT [less likely APPEND] or GET with that same save file as target.

Regards, Chuck