Re: FTPing save files -- locks?

I forgot to add that at least one of the requests which would replace the data yet had failed to open the save file for read-only, actually results in /data loss/ for the request having effected the implicit CLRSAVF against the save file for write, for the issued subcommand [e.g. per (REPLACE on GET and\or the implied clear for PUT]. That there is data loss for the failed request, was why it stuck in my memory. A\the similar data loss issue for an in-use physical data member [CLRPFM] was corrected long ago as I recall... but I would not be surprised if only in a specific direction or for a specific subcommand; and similar problem may exist for any open error other than for the allocation such as "data type(s) not supported for this [non-SQL] open". No clue as to why the original design had the destructive open performed before the read-only open, nor why the fix for PFM would not have changed the order to prevent the condition generally.

Regards, Chuck

CRPence wrote:

CRPence wrote:

<<SNIP>>

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.

Out of curiosity I checked out my recollection, testing using
OS/400 V5R3 from\to the same system with two distinct save files
where one was allocated by DSPSAVF in an alternate session...

Using the FTP subcommand GET to access data from a save file
which is open [in another process] incorrectly gives FTP426
[implying a "member" of the save file is not found] instead of an
allocation error.

Using the FTP subcommand GET with "(REPLACE" to reset the data in
a save file which is open [in another process] incorrectly
returns to the FTP command line without any errors and an empty
prompt line being logged.

The FTP PUT subcommand gives somewhat similar yet possibly
weirder results. Unlike for GET, the failed open for read on PUT
is logged correctly in the joblog as [CPF5729 and] CPF4128 yet is
logged as the 426 error in the FTP session. Open for write on
PUT gives the 426 with "Data transfer ended", plus the next
subcommand and repeats of that same request [e.g. syscmd call
qcmd] end without any results except a blank prompt line being
logged.