Filuphaze   345 pts.  |   Nov 20 2009  7:32PM GMT

You are correct. I am using 0D/0A for CR/LF and that is working fine. My problem is there is an entire blank page on the email when it’s printed. The person receiving the email only wants the one page with the notification on it. I am wondering if there is a hex code etc that shows EOF so it only prints one page.

Thanks

TomLiotta   15415 pts.  |   Nov 21 2009  1:34AM GMT

Have you sent test e-mails to one of your personal external accounts and analyzed the MIME structure? There might be an element that you can control if you determine what all gets sent. (It’s been many years since I last used SNDDST for e-mail.)

Best advice is simply not to use SNDDST since it’s not designed for SMTP.

Tom

Filuphaze   345 pts.  |   Nov 23 2009  5:13PM GMT

Thanks Tom. I have sent test emails and they go through fine except the extra page. What do you suggest using?

TomLiotta   15415 pts.  |   Nov 23 2009  8:53PM GMT

Going through ‘fine’ is one thing. It’s a different thing to download the e-mail item, including all headers, into a text file and viewing it all in a text editor. The physical construction of the e-mail should should different elements such as attachments and their boundaries. (Even though those sections may not be visible when simply viewing the e-mail in a mail client.)

If multiple attachment boundaries exist, it may make sense to explore which parms of SNDDST cause various boundaries to be included. For example, separate boundaries might be generated for DSTD(), MSG(), LONGMSG() and SUBJECT(), even if those are defaulted on the command. By sending test e-mails with different values in those parms, you might uncover the pattern.

Commands can have default values for parms. But parm definitions also allow the CPP to detect whether or not a value is defaulted or if the user actually typed or selected the default value.

For example, the SAVOBJ has a DTACPR() parm that defaults to *DEV. However, on many releases, if you don’t actually enter the DTACPR(*DEV) value, data compression will be ignored regardless of its being the default.

Some of the parms for SNDDST default to *NONE. It’s possible that the default isn’t actually effective if you don’t enter *NONE for the parm. (I have no info on whether that’s the way SNDDST is coded. It just seems like it’s worth verifying if no other possibility comes up.) Try explicitly setting common parms to real values, to *NONE and by letting them default, to see if the physical structure changes.

Shot in the dark, but sometimes those hit something.

If you must use SNDDST, you’ll want to learn all about it.

Tom

Filuphaze   345 pts.  |   Nov 30 2009  5:31PM GMT

Thanks Tom. I tried your suggestion and it appears to be working now.