I agree - compatibility with partners is key, which is why standardized protocols are often chosen over proprietary. This may not be a consideration for all.
As others kindly mentioned, Co:Z SFTP includes support for z/OS data sets, codepage and line terminator conversions etc, etc. It also supports automation on z/OS in the form of customizable notification WTOs, and IBM FTP-compatible user exits. https://dovetail.com/products/sftp.html It is true that restart (of z/OS data set transfers) is not supported, but this turns out not to be as important a requirement as it was years ago when networks were much less reliable. Co:Z is available free under our Community License, Enterprise License and Support agreements are also available. https://dovetail.com/support.html Kirk Wolf http://dovetail.com On Sat, Apr 16, 2022, at 3:45 PM, Steve Beaver wrote: > The whole discussion distills down to. What does your partner site have > including their scheduling system. Unless they have a way that can signal the > file is there to the partner > > Sent from my iPhone > > No one said I could type with one thumb > > > On Apr 16, 2022, at 14:39, Michael Oujesky <[email protected]> wrote: > > > > Due to the capabilities for check-pointing and automatic recovery, I would > > suggest C:D for large file transfers. > > > > Though the transferred file has to be fully landed before processing of the > > data can begin, whereas FTP protocols do allow processing of the data as it > > is received. > > > > If you are doing other transfers via C:D, then licensing cost is not an > > issue. But if C:D is only used for these transfers, then a cost/benefit > > evaluation has to be made versus the cost/impact of error recovery time and > > effort needed to cope with FTP failures. Note that C:D does allow for > > alternate nodes to receive a given transmission. > > > > With both FTP and C:D transfers, I would suggest sending a zero length file > > to signal successful completion. > > > > C:D can spawn a C:D process on the receiving end when transfer has been > > successfully completed or it could spawn task on sending or receiving > > systems to handle an unrecoverable transmission failure. Then there are > > the capabilities of the C:D FileAgent component for additional automation > > options. > > > > Michael > > > > At 09:36 AM 4/16/2022, saurabh khandelwal wrote: > > > >> Hello Group, > >> > >> Currently we are using connect direct in our environment for file > >> transfer. But now, our team like to migrate file transfer from connect > >> direct to sftp. > >> > >> I think, sftp doesn't have any mechanism to find that file has been > >> transferred successfully or not . If we are transferring any big file > >> using sftp and Network connection broken then how it's going to impact the > >> file transfer or sender should again initiate file transfer. > >> > >> In connect direct case we get return code on sender and receiver side > >> which confirm if file transfer is perfectly sent to destination without > >> any issue. > >> > >> Can anybody guide me on this , which facility is best to use sftp or > >> connect direct > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > Kirk Wolf Dovetailed Technologies http://dovetail.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
