An MQ Series solution would not be viable for this application on two counts.
First, I doubt the sender would go for this because it would be too much work on their side to maintain connections to all it's clients. Secondly, MQ has lots of overhead compared to an FTP style process. All the MQMD and other channel related traffic, etc, and in addition, how would you ever know if the file was fully sent, without some additional protocol layer on top of it? On Thu, 10 Jan 2008 10:37:38 +0000, Grant Ward Able <[EMAIL PROTECTED]> wrote: >Has MQSeries been considered? I'd have thought it would have solved most >problems like this..... (unless one of the partners doesnt actually have >MQ installed!) > >-- >Regards - Grant >==================================== >Grant Ward Able >Senior Systems Architect >DTCC >==================================== > > > >"John S. Giltner, Jr." <[EMAIL PROTECTED]> >Sent by: IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> >10/01/2008 02:51 >Please respond to >IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> > > >To >IBM-MAIN@BAMA.UA.EDU >cc > >Subject >Re: File Transfer conundrum > > > > > > >Any reason why you can't ftp directly between the two z/OS system? > >If security is an issue you could use either IPSec tunnels between the >two systems or setup IBM SecureFTP server (SSL'ed FTP). > > > >Bruce Baxter wrote: >> We've routinely exhanged files with business partners running on z/OS >> machines using tape for years. >> >> We're now in the process of converting a number of these to electronic >> means, using in part FTP. This is being done at the behest of one of >our >> business partners, who (IMHO) hasn't thought through all the issues that >the >> use of FTP introduces in this process. The central issue as I see it is >that the >> mainframes at either end of the pipeline are both EBCDIC and record >oriented, >> and the servers and ftp processes that lie between them to facilitate >these >> transfers do not have any inherent concept of record oriented files like >the >> mainframe. >> >> I'm going to treat FIXED BLOCK data separately from VARIABLE BLOCKED >data >> separately. >> >> The first files that we received were FIXED BLOCK, and had been >translated >> from EBCDIC to ASCII, most likely at the first transfer of the file from >z/OS to >> an ASCII based server platform (either Windows or AIX). When they >arrived >> on our z/OS system, we had issues of data corruption because the data >> contained zoned decimal data. After some discussion, we agreed that >we'd >> transfer these files in BINARY mode at all steps along the way. Thus, >all we >> had to do was ensure that the LRECL used for the destination dataset on >> z/OS was the same as the source dataset. This seems to be working OK. >> >> Most recently, we've been having problems with other files that are >VARIABLE >> BLOCKED. We received the first of these files last week, transmitted >from end- >> to-end in BINARY mode. What we got was not at all what we expected. >> We've discovered that the initial FTP from z/OS to the server stripped >off all >> information regarding record length and thus record delineation. Because > >> there aren't any RDWs in front of every record, ftp doesn't know how >long the >> records are and just plunks the data into the destination dataset in >chunks of >> LRECL-4. I did a bunch of research on z/OS FTP and there doesn't appear >to >> be any way to make it convey record length/delineation information to >and >> ASCII platform other than to use ASCII mode. z/OS FTP appears to have >> mechanisms for conveying this between two z/OS FTP systems, but that's >not >> possible here. For the present time, we've had the file shipped with >the initiatl >> movement translating the data from EBCDIC to ASCII and all subsequent >> transfers until the last one back to z/OS in BINARY mode. However, I'm >> concerned about the possibility of data corruption if the translate >tables used >> in the first step and the last step of this files travel aren't exact >inversions of >> each other. This would certainly be possible of the initial ASCII >transfer were >> done to a Windows Code Page 1252 system and the last transfer (having >> CP1252 data) were translating between UTF-8 and CP037. >> >> I'm interested in other folks war stories and what they've implemented >for best >> practices. I've made clear to our developers and end-users that ftp is >> certainly not a direct replacement for tape transfers. It would appear >that we >> need lots of information about all the systems and transformations done >in >> moving the file from one system to another. FTP doesn't convey this >sort of >> information in any way shape or form. >> >> What sort of options are there? >> >> - Transmit/Receive would certainly be one, but would add a lot of >overhead to >> the process. >> - Removal of all non-display data from the files and subjecting them to >ASCII >> translation at every step would also be an option, but that would likely >be >> rejected by our business partner as too much work. >> - Are there any options to z/OS FTP that would allow record formatting >> information to be conveyed in the file, if we presume that we'd transfer >it in >> binary mode at every step. >> >> Has anyone come across any clear helpful best practice type information >or >> sites? I'd be interested in anything anyone has. >> >> Regards, >> Bruce Baxter >> Manager of DP Tech Services >> NYS Dept of Tax and Finance. >> > >---------------------------------------------------------------------- >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 > > > >----------------------------------------- >________________________________________________________ >DTCC DISCLAIMER: This email and any files transmitted with it are >confidential and intended solely for the use of the individual or >entity to whom they are addressed. If you have received this email >in error, please notify us immediately and delete the email and any >attachments from your system. The recipient should check this email >and any attachments for the presence of viruses. The company >accepts no liability for any damage caused by any virus transmitted >by this email. > >---------------------------------------------------------------------- >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
