I meant to respond to some of your other points... On Wednesday, 09/30/2009 at 07:17 EDT, "Schuh, Richard" <[email protected]> wrote:
> I have tried various things while attempting to fix this: > > 1. x'15' at the end of every line. No concatenation, but every line was > double-spaced. > 2. x'15' at the end of lines 4 and 9. No concatenation, but 5 and 10 were > double-spaced. EBCDIC NL is translated to ASCII LF by the STANDARD translation table. > 3. x'0D' at the end of each line. No affect, the error still occurred the same > as the original failure. Not translated. 0x0D is CR in both dialects. A standalone CR has no visual effect. > 4. x'0A' at the end of each line. Error still occurred, and there was a small > square at the end of each line. EBCDIC control character RPT is translated to ASCII 0x1A. If a DOS program were to process the file, it would be logical EOF. EBCDIC LF is 0x25, which is translated by STANDARD to ASCII LF (0x0A). > 5. x'0D0A' at the end of each line. Double-spaced, concatenation still present, > square as above. See above. > 6. Copied the file making the RECFM F, LRECL 94. Success. Other LRECLs > 94 > also work. > > Just for grins, I tried using HTML enrichment. The result was chaos, even if I > sandwiched the report between <pre> and </pre> tags. > > Now for the questions: > > Why just those two concatenations? > > Should any of those attempts have succeeded while the RECFM was V? Yes. Well, maybe. The question is: What is in the file? A hex editor on your PC will tell you. My question about "What form of SENDFILE did you use?" goes to the heart of the issue. Files sent in the plain-text body of the e-mail will be subjected to any and all re-encoding required to get it past the SMTP "sensor net" looking for SMTP controls. CRLFs are the usual victims. By using the MIME options on SENDFILE, the file will be encoded in a way that insulates the file from such predations. Alan Altmark z/VM Development IBM Endicott
