Cobol calling MAIL routines to send SMTP ...

[Art Wiens]

I know 0 about Cobol. Reading through the manual, it really doesn't talk about "system services" the way say, the Basic manual does. Am I correct in assuming that the CALL statement is _the_ way to do such a process? I have also been reading the Utility Routines manual regarding MAIL access and it is quite VMS MAIL centric ... doesn't mention SMTP protocol at all.

We need an existing Cobol program to send SMTP emails. We do not need/want to have any VMS MAIL messages sent/saved. Replies will not come back to VMS (they will be received by an Exchange mailbox/public folder/distro list ... whatever gets decided).

Is this possible? Any chance there's a sample somewhere?

COBOL T5.4-51 (14-DEC-1997! Wonder if it's out of field test yet ;-), VAX/VMS v6.2, TCPware v5.6-2. SMTP is configured and functional.

Cheers,
Art

[Wim Van den Wyngaert]

Am I correct in assuming that the CALL statement is _the_ way to do such a process?

YES

Why not do a spawn in cobol and use DCL to mail ?

Wim

[Art Wiens]

That's the road we're on right now ... just wondering if there's a "better way". There could be approx 50-60 users needing to dispatch messages at any given time. I have some trepidation with "lot's" of users spawning subprocesses. If all 50 "hit the button" at the same time, not sure what would happen.

Art

[Wim Van den Wyngaert · Accepted solution]

I agree but I would go for DCL.
Here is my code in enclosure. In use by our applications. WMS, logical names and some other stuff is specific to our environment.

To direct all replies to a certain mail addres :

define tcpip$smtp_from "art_master@brol.com"

Wim

[Hein van den Heuvel]

It is tempting to just spawn an Email, but I appreciate the performance/resource concern. My gutfeel is that a spawn up to every minute on average is still fine.

On the other hand, it is simple and efficient to just create a subroutine to mail in line. I'd write it in C and call from Cobol, but writting in Cobol is trivial.

I found an example. See below.
You'd have to provide it the MAIL$ symbols for example by creating a helper module MAILDEF as:

$ cre maildef.mar
.TITLE MAILDEF
$MAILDEF GLOBAL
$MAILMSGDEF GLOBAL
.END
Exit
$ macr maildef
$ cob mail
$ link mail,maildef

The Cobol is not mine (Bruce Whacker?), nor my style.
You would have to decide how 'fatal' MAIL$ errors are, and just let Email SIGNAL, or trap and handle. Whether you send or abort mail$send_end should be called.

Enjoy!

identification division.
program-id. sendmail.
data division.
working-storage section.
01 stat pic s9(9) comp.
01 context pic 9(9) comp value 0.
01 null-item.
03 filler pic 9(4) comp value 0.
03 filler pic 9(4) comp value 0.
03 filler pic 9(9) comp value 0.
03 filler pic 9(9) comp value 0.
01 dummy-len pic 9(9) comp.
01 subject pic x(12) value 'test subject'.
01 subject-item.
03 subject-len pic 9(4) comp value 12.
03 filler pic 9(4) comp value external mail$_send_subject.
03 subject-addr pointer value reference subject.
03 filler pointer value reference dummy-len.
03 filler pic 9(9) comp value 0.
01 first_addressee pic x(64) value 'hein'.
01 second_addressee pic x(64) value 'heinvandenheuvel@xxx.yyy'.
01 addr-item.
03 addr-user-len pic 9(4) comp value 64.
03 filler pic 9(4) comp value external mail$_send_username.
03 addr-user-addr pointer value reference first_addressee.
03 filler pointer value reference dummy-len.
03 filler pic 9(9) comp value 0.
01 line1 pic x(6) value 'line 1'.
01 line2 pic x(6) value 'line 2'.
01 body-item.
03 body-file-len pic 9(4) comp value 6.
03 filler pic 9(4) comp value external mail$_send_record.
03 body-file-addr pointer value reference line1.
03 filler pointer value reference dummy-len.
03 filler pic 9(9) comp value 0.
procedure division.
main.
initialize context
call 'mail$send_begin' using context, null-item, null-item
giving stat
if stat is failure
call 'lib$signal' using by value stat
else
call 'mail$send_add_attribute' using context, subject-item, null-item
giving stat
if stat is failure
call 'lib$signal' using by value stat
else
call 'mail$send_add_address' using context, addr-item, null-item
giving stat
if stat is failure
call 'lib$signal' using by value stat
end-if
set addr-user-addr to reference of second_addressee
call 'mail$send_add_address' using
context, addr-item, null-item
giving stat
if stat is failure
call 'lib$signal' using by value stat
else
call 'mail$send_add_bodypart' using
context, body-item, null-item
giving stat
if stat is failure
call 'lib$signal' using by value stat
else
set body-file-addr to reference of line2
call 'mail$send_add_bodypart' using
context, body-item, null-item
giving stat
if stat is failure
call 'lib$signal' using by value stat
else
call 'mail$send_message' using
context, null-item, null-item
giving stat
if stat is failure
call 'lib$signal' using by value stat
end-if
end-if
end-if
end-if
end-if
if stat is failure
call 'mail$send_abort' using context, null-item, null-item
giving stat
if stat is failure
call 'lib$signal' using by value stat
end-if
else
call 'mail$send_end' using context, null-item, null-item
giving stat
if stat is failure
call 'lib$signal' using by value stat
end-if
end-if
exit program.

[Art Wiens]

Thank you both very much! I will pass these on to the programmer and see what she can make of it.

Cheers,
Art

[Wim Van den Wyngaert]

Except that DCL you can correct on the fly without relinking. And it can't abort your program.

My procedure has the advantage :
1) mailing is done in batch (think about big files !), thus increasing speed and possibility to put a low job limit on the queue. Only verifying of params and doing a backup is done in real time.

2) mails files as attachment with auto convert to a pc type

3) has the possibility to convert to PDF (we have listings wider than 1 pc screen and pdf will be match with screen width)

4) will backup/ign locked files (don't know what mail will do)

5) keeps a backup store of the mailed files

6) handle wild cards

7) check maximum mail size (warning only, we have limits of 5 MB)

Fwiw

Wim

[John Gillings]

Art,
An alternative which might be simpler than dealing with MAIL$ routines with item lists and stuff that looks a bit ugly in COBOL, try using routine TCPIP$SMTP_SEND_FROM_FILE.

See TCPIP docs for full details. Basic principle is to put all the addressing details in a text file, then pass it to SFF.

Not sure if it works with TCPware, or as far back as V6.2