Hi Jack,

I am using emailx 4.9(113) and sending attachments. No matter what I do it keeps auto labeling the attachments ATT00001.BIN, etc.

I have made sure the ATT'CONTENT'TYPE() is "".
I also tried loading name="correct name" in ATT'CONTENT'TYPE().

What am I missing.

Ken

Ken,

I've emailed you the current version - 5.0(119) - as a starting point, although I'm not sure that has anything to do with it.

Which ATT'ENCODING option are you using (0=base64, 1=plain, 2=html)?

Is the problem strictly a question of how the attachment is named? Or does it affect the format or actual content of the attached file?

Generally, when people complain about weird email attachment problems, it relates to sending from Outlook and receiving in something else. But that can hardly be an issue here, unless maybe you are using Exchange Server and it is trying to do something special with attachments. (So what kind of SMTP server are you using anyway?)

Otherwise, can you reproduce this with any of the demo EMAILX programs? That would be a helpful starting point. Also, does the problem appear only in one kind of email client? (If you have only one kind of email client handy, Feel free to email me a copy of the message, to verify whether it works with Thunderbird.)

Jack

Okay, I updated to the latest, no help. I sent you an email with the emailx.pdf, then I sent you an email with the emailx.log attached. I also sent them both from my PC's email.

I have a couple more items about emailx, but now that I have the newer version I need to test them again.

Have a nice weekend.
Ken

Seem's to me that the problem is probably in my SendMail. I will study the man and/or google my problem.

Check you next week.

For what's worth, the attachment came through as a PDF just fine at my end (using Thunderbird). (Both when you sent it from EMAILX and from Outlook.) So my suspicion would focus on some issue with the mail reader (which I take to be Outlook?)

Well, I am glad I found this topic. We are having an issuie at Compupay with attachments. We have a program that creates a .CSV file (text formatted). When the program runs it creates a unique file name for the attachment, when finished it closes the file, then emails it (EMAILX on AIX systems) as an attachment. It is going through an Exchange server to Outlook. If this program is run more than once (on different AShell jobs) simultaneously when it emails the attachment 2 or more of the emails will have the wrong attachment file name and the contents of that file is garbled. Very wierd. We, too, have the ATT' variables all set to the defaults. The ATT'COUNT = 1, ATT'FILE(1) is loaded with aunique file name (AMOS format with device: and ppn), ATT'CONTENT'TYPE(1)="" and ATT'ENCODING(1)=0.

Any insight will br greatly appreciated.

Additionally could the EMAILX attachment be related to large file attachments and the EMAILX.CFG configuration LOGLVL = 5? I notice in the LOG the attachment gets picked up with a LOGLVL=5. I am not sure how this all works (not an email guru), but is it possible when multiple EMAILXs get executed and the log is unavailable due to the file size it gets confused or garbled up? Does it wait or how does this function?

Hmmm...
It isn't clear if Ken ever resolved his issue, which would be nice to know, since I wasn't able to get any insight to it on the receiving end (his examples having arrived without exhibiting the problem.) But I'm not sure whether it relates to your issue or not.

I can address the question about how the log works:

It doesn't make any effort at all to coordinate multiple simultaneously log activity at all. EMAILX just opens the log file as an ordinary Basic sequential file for append, and then prints to it as it processes the mail. Under UNIX, when two jobs output to the same sequential file, the OS should guarantee that the file doesn't get corrupted, but it certainly can't guarantee how the two output streams will get intermingled. (Sequential output files are handled as buffered streams, meaning that it accumulates PRINT output in a buffer and then writes the buffer to the file when it gets full. So the likely result would be an intermixing of output at the block (probably 512, but maybe as large as 2048 byte) level.

Although that seems less than ideal, it isn't clear what would be better. Allowing only one process to perform email at a time, making the others wait? Or closing/flushing the log between each output message so that at least the log didn't end up "garbled"? Probably the former would be the best, but I can't see how it has any bearing on the real problem you are reporting, which has to do with the co-mingling of the attachments, which presumably are fully closed (i.e. static) files by the time you make the EMAILX call.

How are you generating the unique attachment names? It's likely that if you are just scanning the disk for the next available file name/number, you wouldn't see the file(s) that are in the process of being created by other jobs, so that you might well end up with multiple jobs writing the same file, essentially ending up with the same situation as we have with the log. (You should be able to see that problem in the attachment files on your server though, and not just in the received attachments.)

It's very hard to believe that the SMTP service, with or with Exchange, has any problem with processing multiple outgoing messages at a time. So it seems most likely that the problem is present in the attachments before you XCALL EMAILX (unlike the situation Ken described).

I would suggest adjusting the mechanism by which you create the unique attachment files to really make sure they are unique. Either incorporate the job or process id into the name, or use XLOCK to obtain exclusivity on the directory search, then create the file, close it, and re-open it for APPEND, and then release the XLOCK.

As for the garbled log, I can make the necessary adjustments to EMAILX.SBX and send you and update, although I'm not sure it's decided which is the best approach. (Presumably even a large email will only take a second or two to transmit, but I'm still not sure I like the idea of allowing only one job to send an email at the same time, since there is no other reason for that restriction. So maybe it would be better to just create multiple copies of the CFG file for each sending process, each with its own log file? Or add an option to have EMAILX automatically create job-specific temporary logs and then merge them in the joint log?) I would also suggest dialing back the LOGLVL to 4 since level 5 is a bit over the top, especially when dealing with attachments.

We are doing small tests, changing the CFG file, etc. The file names are using the job# and they are uniquely named. I will email you a copy of what the EMAILX.LOG looks like. Perhaps that will help. In the meantime we'll keep trying things untl we pinpoint what is causing this. Thanks.