Email message sent is printing 2 pages
I have written a process where a salesrep remotely orders a special item that we don't normally carry and it signals the buyer to order it. When the item is ordered the system emails the salesrep. I use SNDDST with *LMSG with a short note stating the item has been ordered with item, vendor, customer and PO information which only takes up approximately a paragraph. When the salesrep prints the message it prints 2 pages with the second page being blank. I use :/N and :/P in the message to control line feeds etc. Is there a code I can use to show end of file or something. I tried using hex 1A but that doesn't seem to work. Any Ideas? Thanks in advance.
Software/Hardware used:
Software/Hardware used:
ASKED:
November 20, 2009 3:16 PM
UPDATED:
November 30, 2009 5:31 PM
Answer Wiki:
You may want to check out the CR/LF on your printer is on/off.
If you are going to add/modify your code for CR/LF I believe that this is 0D/0A for hex.
Good luck,
Adam
To see all answers submitted to the Answer Wiki: View Answer History.
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
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
Thanks Tom. I have sent test emails and they go through fine except the extra page. What do you suggest using?
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
Thanks Tom. I tried your suggestion and it appears to be working now.