None of our users currently use USS. I would like to avoid it if possible. I heard from the people who actually create the files (They belong to another organization and will not change the files), and the files are actually fixed length, so my solution would work. If the next step in the process requires stripping the last character, I could always use sort to do it. Gadi
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of McKown, John Sent: Thursday, March 18, 2010 2:26 PM To: [email protected] Subject: Re: FTP problem > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of ??? ?? ??? > Sent: Thursday, March 18, 2010 5:03 AM > To: [email protected] > Subject: Re: FTP problem > > Thanks, but I don't think that would work here. > I think I have a solution. > I looked at the file and it looks like it has a fixed record > length of 224. > I used LOCSITE LRECL=225 WRAP > The file is allocated with an LRECL of 224 (224 for the data > and an extra byte for the LF character). > WRAP tells the ftp client to go to a new line instead of > truncating the data. > > Obviously, this will only work if the file has fixed length records. > > Gadi We had something like this here also. The file did have a fixed record length. The problem that the programmers whined about was that their file description had to be extended by one character for the trailing 0x25 (what an LF get translated to in this case). If they didn't then COBOL wouldn't open the file because the LRECL on the file didn't match the size of the record in the COBOL progam. Just out of curiousity, why wouldn't the "ftp to a UNIX file, then use the tr to convert 0x25 to 0x15, then copy to a z/OS dataset" routine work for you? Is it a dislike of using UNIX? Or a dislike of needing a "post processing" step? Lastly, and least likely to be acceptable, is to write your own ftp client which "knows" how to handle this case. I'd probably look at using REXX sockets, if I had to do such a thing. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM ---------------------------------------------------------------------- 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
