using callable email to send a pdf attachment (uuencoded) to Outlook

[MarkOfAus]

We have/had some legacy interactions that required uuencode and mail a while back and we found they did seem to play havoc when using PDF files.

For example, using the available command: $SYS$SYSTEM:TCPIP$UUENCODE.EXE

and an example PDF file: B13681.PDF (B13681.PDF;4                       3.36MB/3.37MB)

Create a symbol:  UUENCODE == "$SYS$SYSTEM:TCPIP$UUENCODE.EXE"

$ uuencode B13681.PDF B13681.UUE

Renders a file:

B13681.UUE;2                       2.15MB/2.25MB

Then transport it:

$ mail /subject="Test" B13681.UUE smtp%"my.email.address"

It arrives at MS Exchange as garbage (corrupted somewhere).

However, if I zip the pdf up (using zip from one of the Freeware CDs), and uuencode it again:

$ uuencode B13681.ZIP B13681.UUE

The resulting file is:
B13681.UUE;3                       1.58MB/1.68MB

I then transport it:

$ mail /subject="Test" B13681.UUE smtp%"my.email.address"

It arrives, is unzipped and looks/feels and acts like a PDF.

Conclusion? Something happens with pdfs and uuencode. Try to zip it up and see if it changes the outcome.

Alternatively, move to MIME as Hoff suggests.

[H.Becker]

What's the record format of the PDF?

I can reproduce a corruption with a PDF in "Stream" format.  After the uuencode-uudecode sequence the first difference is a 0x0d 0x0a in the original PDF and a 0x0a in the uudecoded PDF.

When I do a SET FILE/ATTRIBUTE with RFM=STMLF to the original file this difference no longer shows (the uudecoded file has an additional 0x0a at the end of the file, anything else is as in the original PDF).

Using RFM=FIX and LRL=512 seem sto have the same effect for the CR LF content, but then the additional trailing 0x0a is in its own record/disk block.

(Using UUxxCODE from HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 5)

[Rich Bordewick]

Hi,

I would like to appoligize for making you guess.  I was not really sure where my problem was originating.

The purpose of my changes are an attempt to get away from paper.  The users would print a p/o on a laser printer, scan it, and the email to a vendor.  The head office would also print copies of the purchase orders and mail them to other office locations.  Email makes this all simple.

The purchase order form report gets created with the p/o form macro number reference and the purchase order detail.  This p/o report file is then converted using an FDL to set the record format to Stream_LF (recommeded by the PCL2PDF vendor, and the test skipping this step produced unusable PDF's).  The converted report is then input into the PCL2PDF conversion program along with the PCL form macro file.  The PDF output file is read by my email subroutines and converted by a UUENCODE subroutine to create an email attachment.

What I referred to as "callable email"  are OpenVMS Mail Utility Routines.

The record format of the PCL2PDF output PDF file is Stream_LF, maximum 0 bytes, longest 32767.  I believe the longest physical record is around 5000-6000 characters long.  My test file had only 5 lines for 21 purchase orders.

I have spent some time changing the process to use MIME and have some output.  However, when it gets to Outlook the MIME file is not an attachment, but is in the body of the email and binary.

My I64 system is unlikely to be upgraded any time soon, and more likely to be replaced in the future by a new and unknown system.

Thank you again for your patience and suggestions.

[Rich Bordewick · Accepted solution]

---

@MarkOfAus wrote:

We have/had some legacy interactions that required uuencode and mail a while back and we found they did seem to play havoc when using PDF files.

For example, using the available command: $SYS$SYSTEM:TCPIP$UUENCODE.EXE

and an example PDF file: B13681.PDF (B13681.PDF;4                       3.36MB/3.37MB)

Create a symbol:  UUENCODE == "$SYS$SYSTEM:TCPIP$UUENCODE.EXE"

$ uuencode B13681.PDF B13681.UUE

Renders a file:

B13681.UUE;2                       2.15MB/2.25MB

Then transport it:

$ mail /subject="Test" B13681.UUE smtp%"my.email.address"

It arrives at MS Exchange as garbage (corrupted somewhere).

However, if I zip the pdf up (using zip from one of the Freeware CDs), and uuencode it again:

$ uuencode B13681.ZIP B13681.UUE

The resulting file is:
B13681.UUE;3                       1.58MB/1.68MB

I then transport it:

$ mail /subject="Test" B13681.UUE smtp%"my.email.address"

It arrives, is unzipped and looks/feels and acts like a PDF.

Conclusion? Something happens with pdfs and uuencode. Try to zip it up and see if it changes the outcome.

Alternatively, move to MIME as Hoff suggests.

---

Winner!

I don't have a zip on my I64 at this time.  There were some minor errors in the attachment, lost some of the form graphics. I will look into getting a zip program.

Again, thank you all.

[Hoff]

Please use the right tool: MIME.

Yes, you can use a hammer to drive in screws, but it just doesn't work very well.  

...zip for OpenVMS

[John Gillings]

Rich,

    This sounds hauntingly familiar... I can't find the details at the moment, but I remember hitting a strange magic number when using UUENCODE and MAIL. Messages over the magic size get extra characters inserted, which looks like corruption. I couldn't find a better workaround than using ZIP first.

ZIP can be relied on to correctly pack lines into predictable size chunks.

If you have some time to waste, you can determine the exact limit using a binary search, or digging through the binary contents of your messages. If your file is smaller than the magic number, you can post it as is, otherwise zip if first.