Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

VMS Mail to Exchange 2010

 
jjinva
Advisor

VMS Mail to Exchange 2010

VMS 8.3 - HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 5

I have an application that emails reports within the body of the email to Users. This worked fine on Exchange 2003.

Testing to Exchange 2010 I have run into a problem. When the reports are created they insert a Character.

FROM the SMTP log:

send buf=\00\0d\0a.

Exchange chokes on this and doesn't write any data after the Null. Is there some way to get SMTP to ignore this character and send it out without it?
5 REPLIES 5
Hoff
Honored Contributor

Re: VMS Mail to Exchange 2010

Until proven otherwise, your application will be considered to be broken. With typical cases, the bug is yours until you can prove it's not.

And that the application worked does NOT mean it is bug-free.

Debug and distill that case or a reproducer.

When you can get to a reproducer of whatever is going on here and to some indication that this isn't an application bug, you'll then want to call HP support directly.

Bob Blunt
Respected Contributor

Re: VMS Mail to Exchange 2010

What in your application changed? Was it the VMS end or was it "just" Exchange 2010?

Although I agree with Hoff in principle if you didn't change anything on the VMS part of the application then, IMHO, the issue lies in how Exchange is working. Granted you have probably been generating that in your application for a long time but if you changed nothing on the VMS side then it shouldn't have just magically started generating and sending them.

SO, the standard litany...

Did anything change, at all, with the OpenVMS side of the equation? Any patches, O/S upgrades, TCPIP Services ECOs or new code or new builds of what generates the reports to your users? If the answer is no then, unfortunately, you'll still probably have to change the tools that create your reports that get sent as a message. Unless there's some setting or widget on Exchange that's inserting the then eliminating it at the source is the only answer.

What are you using to generate the reports that get sent to users? Some languages have their own particular styles of output that may be inserting that character. There's not much that you've given us to help you and guessing won't fix it unless someone gets really lucky.

bob
jjinva
Advisor

Re: VMS Mail to Exchange 2010

Nothing has changed on our side. I know it's how Exchange 2010 is handling the data. Exchange 2003 mailboxes still work as before. If I remove the Nulls from the report it works as expected to Ex 2010.

It is our Application Software that generates the Characters. I have gone back to the Application Developers to see if there is some way to suppress the Nulls in the Reports. Havn't heard from them yet.

The Reports are straight Ascii text with a standard heading, body and Summary sections seperated by the Nulls/LF/CR and mailed to users using:

Mail/Subj=Subject File.txt "smtp%user@domain.com" syntax.

I was just wondering if anyone knew any tricks that could help. I have seen this forum come up with some creative solutions as I read it regularly.

I would be happy to provide any other info that you might need.
Hoff
Honored Contributor

Re: VMS Mail to Exchange 2010

GIGO.

Garbage In, Garbage Out.

You can fix the code that generates these files.

Or add some hacks to post-process the files.

If your goal is maintainability, then go for the former.

Otherwise, go with the latter.

One potential alternative for extending the complexity in the implementation is to determine if MIME-encoding the document gets past whatever is happening within Exchange here. This testing via the MIME utility on VMS.

But the principles of GIGO imply that null byte is likely still going to cause issues somewhere downstream.

If you want help with null-byte processing or extensions within Windows Server and Exchange Server, this isn't the best forum for that.
Craig A Berry
Honored Contributor

Re: VMS Mail to Exchange 2010

Most likely the new version of Exchange is doing the right thing based on the Content-Transfer-Encoding and Content-Type headers (or lack thereof) in the message you are sending it. You'll likely need more control over those headers than you can get using VMS Mail. See

$ help mime