Donald >...> The cpp files are currently on my windows system. I am attempting to send >them to my z/OS system.
Your problem is that you want to send some files from your Windows system to z/OS. The source files are represented in ASCII. The destination files are to be represented in EBCDIC I assume. >...> I have seen this sort of thing when an ASCII file has UNIX style line >endings (LF only) and the ftp is done by a Windows system (which wants CRLF). The "line ending" or "record delimiter" indication in ASCII is a single "line feed" (LF) character in the case of these particular files because - relying on the wisdom demonstrated in this thread - they happen to follow some much despised UNIX convention. It so happens that the "line ending" or "record delimiter" indication in EBCDIC is a single "new line" (NL) character. That should make translation easy! The usual problem with the "line ending" or "record delimiter" indication when "moving" from an ASCII representation to an EBCDIC representation or vice versa is that EBCDIC uses the single NL character while ASCII uses a combination of two characters, a "carriage return" (CR) as well as the LF in the order CRLF. Obviously translation involving one character becoming two or two characters becoming one is - how shall I put this? - a challenge![1] But you don't have that problem, so it should be easy! What I have tried to explain above may well be what your post was supposed to convey but it wasn't crystal clear to me - and perhaps others - so I've attempted to paraphrase. - [1] It helps explain why I am at all involved in this topic that one particular "platform", namely NCP/NPSI, rejected the challenge for the very good reason that the Communication Controller instruction set, while having a S/360 origin, never bothered with the "move character" instruction - or I suppose any of the "storage" to "storage" instructions. Thus, if a primary LU program that was capable of conversing interactively with an LU type 1 secondary LU, as properly constituted, for example a 3767, needed to converse with an asynchronous ASCII device (NTO or X.25 PAD), the program needed to be informed by means of the TERM=TWX operand and value on the relevant LU statement in VTAM that the data stream, rather than using the EBCDIC NL character as the "line ending" indication, used the EBCDIC "flavour" of the CR character followed immediately by the EBCDIC "flavour" of the LF character. The CRLF could then simply be translated from EBCDIC to ASCII and vice versa. - Chris Mason On Mon, 6 Feb 2012 11:54:23 -0600, Donald Likens <[email protected]> wrote: >I have not made it work yet but I am convinced that the best way to handle >sending files that use LF (unix) new line indicator to a system that >understands CRLF as the new line indicator is to use a special translation >table (Translate x'15' to x'25'). In the z/OS case I updated the >ASCII-to-EBCDIC table. I simply have not been able to get FTP to read my >special table yet. > ... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
