SNDDST with a SPLF - wont send in batch

[David Abramowitz]

One possibility is that you are submitting the job to batch with a different library list than that of your interactive job. Dave

[Terry Winchester]

I seem to recall that there's a 32 character limitation on CL parameters of character variables. You could try doing a SNDMSG to the console via QSYSOPR with the &email parameter and see what it looks like. If its incorrect, try increasing the size by 1 in your sending program (41) and change the last position to a certain value (using %SST). Then in the your receiving program you'll have to extract the the first 40 characters and use that as your email address. Hopefully, somebody will correct me if I'm off-base here Terry

[Guest.Visitor]

When you submit the job to batch are you padding out the &EMAIL parameter with enough spaces to make it 40 bytes? In other words, the difference between 'a@b.com' and 'a@b.com {33 spaces}'. I think if you don't make that field exactly 40 bytes you'll end up with garbage in that variable. You can use the STRSRVJOB command to put the batch job in debug to verify this. As far as the subject of your email goes, the DSTD parameter will not be used. You'll have to use the CHGDOCD command to change the DOCD of sum020.txt. HTH, Mark

[Guest.Visitor]

I'm emailing a report, also using cpysplf, cpytopcd, snddst. I run a CL and it works great as long as it's called from the interactive Inquiry. When I change the CL from a call from a sbmjob, it never sends the document. I follow the job log and it says the send distribution completed successfully. If I go into the submitted job and hard code the email address it works, but when i change it to use the same address passed as a parameter I never geth the email. One more thing - the dstd (subject line) field always has in it the name of the file I have attached, rather than the text in the dsts parameter. Anyone have anything like this happening? Thanks, -jd-

---

Code

[Guest.Visitor]

I just finished testing, by doing same call to the CL, which runs the report, etc. both with padding the address out to 40 positions and with not padding it. The padding fixed it - so did the chgdocd. I just don't get why a sbmjob compresses out the blanks in a character parameter like that, when it's defined as 40 positions. But thanks, your help did it...jd