Okay Bruce... I forgot that you were the poster. I believe another forum member mentioned this...
Would XMIT/RECEIVE work? I ask because at another location/client there was a need to keep backup copies of numerous mainframe files off of the mainframe. So on a periodic basis, a mainframe job would kick off, "unload" the files to XMIT format and then FTP that file down to a PC/workstation attached to the host network. On that workstation I had a VB script that would monitor the incoming directory and whenever it found a new file it would then either email or FTP the file to another location. (email or FTP was destination specific). Once the file was "sent", it would be moved to another directory to get it out of the way... Worked great! During testing I had a "receive" job defined to the job scheduler so whenever a specific file was created, the receive job would be kicked off using the file name as a JCL parameter. This file would then be "received" back into the original format. To test the process I would drag-n-drop a file into a different PC/workstation directory (separate from the one mentioned above). Another VB script would see the new file and then FTP that file to the host. Once there, the job would be kicked off and the file received. Again, JMTC -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Baxter Sent: Thursday, January 10, 2008 10:53 PM To: [email protected] Subject: Re: File Transfer conundrum I'm the original poster, and yours is an intersting thought. There's no financial partners involved that I know of, and S.W.I.F.T. would not really be applicable. Some of the other posters mentioned security issues, and they're not really a concern here since the transfers that occur on public networks are done securely and encrypted. At issue, I think are the data conversions at either end, which, with FTP require knowledge of the Code Pages and converstions that have taken place. On Thu, 10 Jan 2008 21:10:04 -0500, Gary Green <[EMAIL PROTECTED] SYSTEMS.COM> wrote: >I lost track of who posted the original inquiry, so take this for what >it's worth. > >If the requirement is in the financial industry, could the >communications between the two/various systems use S.W.I.F.T. (Society >for Worldwide Interbank Financial Telecommunications)? It's been some >time since I wrote anything for SWIFT, but it was extremely secure and >most financial institutions should be linked in. > >When I did some work, it was used in the securities market, primarily >for payments, foreign exchange, securities, etc... However, there were >rumblings that the SWIFT organization was thinking about opening up the >network for other financial "transactions"; which I took to mean data >exchange... > >JMTC > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf >Of Ed Gould >Sent: Thursday, January 10, 2008 8:52 PM >To: [email protected] >Subject: Re: File Transfer conundrum > >On Jan 10, 2008, at 11:16 AM, Hal Merritt wrote: > >> My guess is that many shops are implementing PC to PC transfers and >> buying some really expensive software to facilitate the process. >> That is >> host>pc>network>pc>host. >> >> So far, we have been somewhat successful in insisting on a fully >> automated, z/os based solution on our side. Our most compelling >> argument is that we are not supposed to move sensitive data in the >> open over any network, nor is the data supposed to reside in the open >> on any server, even in a buffer. As much as the PC folks don't like >> to admit it, they simply cannot meet that requirement. They can come >> close, but there seems to always be a point where the data can be >> intercepted. >> >> > >Hal, > >Even though my bosses boss was big on PC's he also knew that PC file >transfer was well lets say less than perfect. He was the person who >pushed SNA and made the budget available to convert to SNA and the >hardware associated with it. He lobbied for the money because he knew >that pc file transfer in the financial community was less than good. >We in the financial community put data integrity on a pedestal that >tested everything every step of the way. A long time ago they had an >OEM (name >withheld) vendor and there was no data integrity checking all they >cared about was being cheap. We were racked over the coals all the time >as we were >essentially sending out good data but the data along the line was being >corrupted somewhere along the line. >Usually it was a some important field that needed to have to have the >entire file retransmitted. more than a few times a broker could not >trade any X because data from our company was less than lets say >accurate due to transmission and or equipment. Our side sent it out OK >but somewhere along the line after it left something got corrupted. >After we ditched the OEM vendor and we went to SNA we never had one >piece of data go bad. We had cases where there was a tape issue on the >receiving (data check or broken tape etc) that required a >retransmission but not one in several million file transfers a day >every was caused by "us". PC file transfer sucks PERIOD. I download on >my MAC several hundred files a day and at least once a day some >file is corrupted. > >Ed > > > <http://e-mail- servers.com/ee2878cf37f593a6c827c73598cee1edworker.jpg> > >---------------------------------------------------------------------- >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 ---------------------------------------------------------------------- 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 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.0/1216 - Release Date: 1/9/2008 10:16 AM <http://e-mail-servers.com/e38ce90e1141147d9336c03df263e562worker.jpg> ---------------------------------------------------------------------- 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
