As far as I can see so far, the target of such a transfer is almost always some tool or process that does not support any of the DBMS solutions. But even if they did, the costs of crafting and deploying a DBMS infrastructure is often complex and prohibitively expensive.
I agree with you that there is a lot wrong with bulk data movement. But that seems to be the most cost effective solution by far at the current state of the technology. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Timothy Sipples Sent: Friday, February 12, 2010 5:34 AM To: [email protected] Subject: Re: FTP problems If the file transfer is for purposes of application integration (or similar), then I would (often) suggest an application interface of some sort as an alternative. Since the platform currently receiving the files is Microsoft Windows, then presumably Windows-friendly interfaces such as Web services (SOAP, etc.) and/or ODBC would be possible candidates. Or even something as basic as CIFS/SMB or SMTP. But that's jumping ahead a little. I don't necessarily object to FTP as a protocol. I'm asking about file transfer (generically) and the reason for it in this particular situation. Why are files getting transferred at all? I'm asking a architectural question, quite simply. There are myriad architectural disadvantages to bulk record file transfer as an application integration pattern. Perhaps you've slammed into only one of them (operational challenges) so far. Among the other disadvantages: probable conversion of two on-line/real-time applications into a delayed/batch interaction (with its associated reconcilation and other issues), complete loss of enterprise security context for the data, potentially harder-to-manage workload spikes driven by wall clock deadlines for transfer, potential waste of resources repeatedly dumping duplicate/unprocessed records, and inflated storage costs. So I'm curious. I might have some suggestions to offer. File transfer of any sort, between any two systems, is nothing more than taking card decks and trucking them or footing them between system A and system B, just like in the 1950s. And sometimes that's entirely appropriate. But file transfer is way, way overused as a deployment pattern, in my experience. And I'm not sure so many of us should be spending so much time and attention moving card decks these days. So I ask. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
