Re: FW: SYSOUT dynamic allocation in COBOL - but a little problem

2009-03-18 Thread Steve Comstock

Steve Comstock wrote:

Steve Comstock wrote:

Bill Klein wrote:
I may be missing something, but if you know at compile-time (when you 
can
set an environment variable) that you want the output to go to 
SYSOUT, why
are you using files (with OPEN, WRITE, etc) and not just doing a 
DISPLAY

statement?  Either that or call CEEMSG.

I think those are more normal ways in COBOL to send output to SYSOUT.

David Speake david.spe...@bcbssc.com wrote in message
news:listserv%200903152048381559.0...@bama.ua.edu...
I have used dynamic allocation via the environmental variables in 
COBOL.

Thanks to Steve Comstock and others for getting me started.
But I see nothing about SYSOUT and it says a DSN is required.
My need is for a //X DD SYSOUT=(B,SMTP)


Bill,

He's not really sending things to a true SYSOUT file, but to an
email server. However, you could do such a thing by hardcoding
the DD name and opening the file, writing, then closing, and
then re-opening; each file should be sent separately.

Just leave a single DD statement, //MAILOUT  DD  SYSOUT=(B,SMTP)
if you like. No need for dynamic allocation at all.


Don't have time to test right now. I will if I get a chance later.


OK. Today I took some time and tested it. Works like a champ; it
just wasn't clear on the original post that the intent was to go
to SMTP.

So I wrote some code that sends 10 records to each entry in
a table of email addresses. The essential logic is:

open mailout
write email header records
write 10 data records
  (get input data record,
   format
   write it out) - 10 times
write email trailer records
close mailout

repeat that in a loop for each email addressee you have.

No need for dynamic allocation. Happy to send the code to
anyone who requests it.


Well, now that I look at things again, I see it works
except...

All the emails get concatenated in the SYSOUT file, and
only the first actually gets sent!

I had to rework the logic a little bit to only send a 'quit'
line after all the other messages had been sent. So now it
works as expected.



Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

== Check out the Trainer's Friend Store to purchase z/OS  ==
== application developer toolkits. Sample code in four==
== programming languages, JCL to Assemble or compile, ==
== bind and test. ==
==   http://www.trainersfriend.com/TTFStore/index.html==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-17 Thread Tom Marchant
On Mon, 16 Mar 2009 16:01:20 -0500, Paul Gilmartin wrote:

On Mon, 16 Mar 2009 15:08:48 -0500, Tom Marchant wrote:

DISPLAY always goes to DDName SYSOUT, which can be a data 
set or a spooled data set (SYSOUT=x).

The OP has a need for the output to go to a DD that will not contain other
information.  It is not uncommon for a program to have multiple distinct
output data sets, some of which might be handled by the Job Entry Subsystem.

The need to send multiple reports to multiple distinct output data
sets, some of which might be handled by the Job Entry Subsystem.
sounds like a strong argument to use OPEN, WRITE, etc in preferende
to more normal ways.

(DDName SYSOUT?  Not SYSPRINT?  Not SYSTERM?  COBOL seems
to want to be the misfit.  Will it accept an alternate DDNAME
list as a second PARM?)

Indeed.  It has been a long time since I was a COBOL programmer.

DISPLAY ... UPON ...
UPON can specify SYSOUT, SYSLIST, SYSLST, SYSPUNCH, SYSPCH or CONSOLE.

DISPLAY was not designed as a general purpose file output statement.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-17 Thread Steve Comstock

Steve Comstock wrote:

Bill Klein wrote:

I may be missing something, but if you know at compile-time (when you can
set an environment variable) that you want the output to go to 
SYSOUT, why
are you using files (with OPEN, WRITE, etc) and not just doing a 
DISPLAY

statement?  Either that or call CEEMSG.

I think those are more normal ways in COBOL to send output to SYSOUT.

David Speake david.spe...@bcbssc.com wrote in message
news:listserv%200903152048381559.0...@bama.ua.edu...

I have used dynamic allocation via the environmental variables in COBOL.
Thanks to Steve Comstock and others for getting me started.
But I see nothing about SYSOUT and it says a DSN is required.
My need is for a //X DD SYSOUT=(B,SMTP)


Bill,

He's not really sending things to a true SYSOUT file, but to an
email server. However, you could do such a thing by hardcoding
the DD name and opening the file, writing, then closing, and
then re-opening; each file should be sent separately.

Just leave a single DD statement, //MAILOUT  DD  SYSOUT=(B,SMTP)
if you like. No need for dynamic allocation at all.


Don't have time to test right now. I will if I get a chance later.


OK. Today I took some time and tested it. Works like a champ; it
just wasn't clear on the original post that the intent was to go
to SMTP.

So I wrote some code that sends 10 records to each entry in
a table of email addresses. The essential logic is:

open mailout
write email header records
write 10 data records
  (get input data record,
   format
   write it out) - 10 times
write email trailer records
close mailout

repeat that in a loop for each email addressee you have.

No need for dynamic allocation. Happy to send the code to
anyone who requests it.



Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

== Check out the Trainer's Friend Store to purchase z/OS  ==
== application developer toolkits. Sample code in four==
== programming languages, JCL to Assemble or compile, ==
== bind and test. ==
==   http://www.trainersfriend.com/TTFStore/index.html==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-17 Thread Gibney, Dave
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
 Behalf Of Steve Comstock
 Sent: Tuesday, March 17, 2009 9:47 AM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re: FW: SYSOUT dynamic allocation in COBOL
 
 Steve Comstock wrote:
  Bill Klein wrote:
  I may be missing something, but if you know at compile-time (when
 you can
  set an environment variable) that you want the output to go to
  SYSOUT, why
  are you using files (with OPEN, WRITE, etc) and not just doing a
  DISPLAY
  statement?  Either that or call CEEMSG.
 
  I think those are more normal ways in COBOL to send output to
 SYSOUT.
 
  David Speake david.spe...@bcbssc.com wrote in message
  news:listserv%200903152048381559.0...@bama.ua.edu...
  I have used dynamic allocation via the environmental variables in
 COBOL.
  Thanks to Steve Comstock and others for getting me started.
  But I see nothing about SYSOUT and it says a DSN is required.
  My need is for a //X DD SYSOUT=(B,SMTP)
 
  Bill,
 
  He's not really sending things to a true SYSOUT file, but to an
  email server. However, you could do such a thing by hardcoding
  the DD name and opening the file, writing, then closing, and
  then re-opening; each file should be sent separately.
 
  Just leave a single DD statement, //MAILOUT  DD  SYSOUT=(B,SMTP)
  if you like. No need for dynamic allocation at all.
 
 
  Don't have time to test right now. I will if I get a chance later.
 
 OK. Today I took some time and tested it. Works like a champ; it
 just wasn't clear on the original post that the intent was to go
 to SMTP.
 
 So I wrote some code that sends 10 records to each entry in
 a table of email addresses. The essential logic is:
 
 open mailout
 write email header records
 write 10 data records
(get input data record,
 format
 write it out) - 10 times
 write email trailer records
 close mailout
 
 repeat that in a loop for each email addressee you have.
 
 No need for dynamic allocation. Happy to send the code to
 anyone who requests it.
 

   Actually, I don't think you even need to close the file. The correct
Incantation in the header or trailer (I don't remember the specifics)
will allow multiple messages to multiple destinations. The gotcha is
that if you hit SMTP with a large multi* file, since its simple minded
and single threaded, a fair sized backlog can build up while it
processes your large file.

Dave Gibney
Information Technology Services
Washington State University

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-17 Thread Ulrich Krueger
Steve,
There's just one fly in the ointment that I'd like to point out ...
If you create *one* file containing *multiple* email messages and send it to
SYSOUT=(B,SMTP) ... I mean, yes, it'll work, but it'll tie up the SMTP task
and cause performance problems if your SMTP task is busy with other emails,
too.
The SMTP task is a single-minded process. It performs only one action at a
time. 
While busy reading a file from SPOOL, SMTP will take this file apart and
store each email message that it contains on disk in 2 files (1 address book
and 1 message contents file). Only after all email messages contained in
this one SPOOL file are stored, will SMTP continue with its other duties,
such as listening on the network for incoming emails, or sending one of the
stored emails).

In my experience with a relatively busy M/F site posting hundreds of
individual emails per day (some of them time-critical pager event
notifications), liberally sprinkled with mass-mails (single SPOOL files
containing anywhere from 10 up to 3,000 email messages), I have to say that
SMTP performance was greatly improved once I broke those mass-mails into
individual SPOOL files containing only one email per file. A mass-mail SPOOL
file containing 3,000 emails took several hours to be read in and stored as
disk files on the busy M/F. Meanwhile, nothing else happened in SMTP ... not
a single stored email was sent, no emails were received, pager notifications
did not go out in a timely manner, Operators got calls from users, Operators
called me saying SMTP is hung or worse, cancelled SMTP ... it was a mess.
With one email message per SPOOL file, SMTP could process the emails in the
way it was designed to do, in a round-robin fashion: read 1 email from SPOOL
and store it, send one or more stored emails, receive incoming emails and
store them, and so on.

Additional improvements could be realized when I stored those mass-mail
SPOOL files with a lower JES2 queue priority, thus allowing individual
emails to go right ahead, in and out of the system in a few minutes without
being delayed too much by the lower importance mass mail traffic.

I urge you to change your process and use BPXWDYN to dynamically allocate
and free one SPOOL file for each individual email message. Your SMTP mail
task and your user community will thank you for that (or at least you won't
have any complaints :-).

Regards,
Ulrich Krueger

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Steve Comstock
Sent: Tuesday, March 17, 2009 09:47
To: IBM-MAIN@bama.ua.edu
Subject: Re: FW: SYSOUT dynamic allocation in COBOL

Steve Comstock wrote:
snipped
OK. Today I took some time and tested it. Works like a champ; it
just wasn't clear on the original post that the intent was to go
to SMTP.

So I wrote some code that sends 10 records to each entry in
a table of email addresses. The essential logic is:

open mailout
write email header records
write 10 data records
   (get input data record,
format
write it out) - 10 times
write email trailer records
close mailout

repeat that in a loop for each email addressee you have.

No need for dynamic allocation. Happy to send the code to
anyone who requests it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-17 Thread Steve Comstock

Ulrich Krueger wrote:

Steve,
There's just one fly in the ointment that I'd like to point out ...
If you create *one* file containing *multiple* email messages and send it to
SYSOUT=(B,SMTP) ... I mean, yes, it'll work, but it'll tie up the SMTP task
and cause performance problems if your SMTP task is busy with other emails,
too.
The SMTP task is a single-minded process. It performs only one action at a
time. 
While busy reading a file from SPOOL, SMTP will take this file apart and

store each email message that it contains on disk in 2 files (1 address book
and 1 message contents file). Only after all email messages contained in
this one SPOOL file are stored, will SMTP continue with its other duties,
such as listening on the network for incoming emails, or sending one of the
stored emails).

In my experience with a relatively busy M/F site posting hundreds of
individual emails per day (some of them time-critical pager event
notifications), liberally sprinkled with mass-mails (single SPOOL files
containing anywhere from 10 up to 3,000 email messages), I have to say that
SMTP performance was greatly improved once I broke those mass-mails into
individual SPOOL files containing only one email per file. A mass-mail SPOOL
file containing 3,000 emails took several hours to be read in and stored as
disk files on the busy M/F. Meanwhile, nothing else happened in SMTP ... not
a single stored email was sent, no emails were received, pager notifications
did not go out in a timely manner, Operators got calls from users, Operators
called me saying SMTP is hung or worse, cancelled SMTP ... it was a mess.
With one email message per SPOOL file, SMTP could process the emails in the
way it was designed to do, in a round-robin fashion: read 1 email from SPOOL
and store it, send one or more stored emails, receive incoming emails and
store them, and so on.

Additional improvements could be realized when I stored those mass-mail
SPOOL files with a lower JES2 queue priority, thus allowing individual
emails to go right ahead, in and out of the system in a few minutes without
being delayed too much by the lower importance mass mail traffic.

I urge you to change your process and use BPXWDYN to dynamically allocate
and free one SPOOL file for each individual email message. Your SMTP mail
task and your user community will thank you for that (or at least you won't
have any complaints :-).

Regards,
Ulrich Krueger


Ulrich,

Well, that would be an issue if there was any heavy use of SMTP here.
I was just trying to verify the logic would work, to satisfy the
original post.

With only one person (me) sending emails (only occasionally and all
small), and never more than three users logged on to our zPad at one
time, the issues you raise are simply not present.



Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

== Check out the Trainer's Friend Store to purchase z/OS  ==
== application developer toolkits. Sample code in four==
== programming languages, JCL to Assemble or compile, ==
== bind and test. ==
==   http://www.trainersfriend.com/TTFStore/index.html==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-17 Thread Ulrich Krueger
Glad to hear that this is a non-issue for your shop, Steve.
I just felt like I had to climb up on my soap-box and point this potential
pitfall out to you as well as to the rest of the user community so they
don't have to suffer through the same issues that I had to experience.

If you happen to have some more time to play with it, I sure would like to
see some COBOL code that uses dynamic allocation to create one SPOOL file
per email message.
At my shop, when I was finally able to pinpoint where the SMTP performance
problems originated from, I was lucky. A single JCL-procedure was used to
create the mass-mail file(s). So, instead of sending it directly to
SYSOUT=(B,SMTP), I added a step to execute a REXX - exec which I had
written. It split the big file into individual SPOOL files, one per email
message. Worked like a charm, once I had it all figured out. No more SMTP
performance problems, no more nasty calls from users.


Regards,
Ulrich Krueger


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Steve Comstock
Sent: Tuesday, March 17, 2009 10:57
To: IBM-MAIN@bama.ua.edu
Subject: Re: FW: SYSOUT dynamic allocation in COBOL

Ulrich,

Well, that would be an issue if there was any heavy use of SMTP here.
I was just trying to verify the logic would work, to satisfy the
original post.

With only one person (me) sending emails (only occasionally and all
small), and never more than three users logged on to our zPad at one
time, the issues you raise are simply not present.



Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

   z/OS Application development made easier
 * Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

== Check out the Trainer's Friend Store to purchase z/OS  ==
== application developer toolkits. Sample code in four==
== programming languages, JCL to Assemble or compile, ==
== bind and test. ==
==   http://www.trainersfriend.com/TTFStore/index.html==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-17 Thread Tony Harminc
2009/3/17 Ulrich Krueger u...@pacbell.net:
 Glad to hear that this is a non-issue for your shop, Steve.
 I just felt like I had to climb up on my soap-box and point this potential
 pitfall out to you as well as to the rest of the user community so they
 don't have to suffer through the same issues that I had to experience.

 If you happen to have some more time to play with it, I sure would like to
 see some COBOL code that uses dynamic allocation to create one SPOOL file
 per email message.
 At my shop, when I was finally able to pinpoint where the SMTP performance
 problems originated from, I was lucky. A single JCL-procedure was used to
 create the mass-mail file(s). So, instead of sending it directly to
 SYSOUT=(B,SMTP), I added a step to execute a REXX - exec which I had
 written. It split the big file into individual SPOOL files, one per email
 message. Worked like a charm, once I had it all figured out. No more SMTP
 performance problems, no more nasty calls from users.

Shouldn't someone fix the SMTP server instead...?

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-17 Thread Ulrich Krueger
Tony,
While I was trying to troubleshoot my mass-mail performance issue some years
ago, I talked with IBM and learned a lot about the internal workings of the
SMTP server.
The bottom line is (as far as I could determine): It works as designed, if
you restrict yourself to having no more than one email per SPOOL file. 
Of course, there's nothing in the code or the doc that prevents you from
packing more than one email into a single SPOOL file. However, the more
emails you have per SPOOL file, the worse the performance gets. 
The SMTP server was written at the time when IBM added TCP/IP support to
MVS. It was written in PASCAL at that time, and it was written as a
single-task server.
If you need something better / faster / more powerful, you might want to
check out the UNIX (OMVS) - based email programs. Documentation and Redbooks
about that are available at IBM.


Regards,
Ulrich Krueger


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Tony Harminc
Sent: Tuesday, March 17, 2009 11:40
To: IBM-MAIN@bama.ua.edu
Subject: Re: FW: SYSOUT dynamic allocation in COBOL
snipped

Shouldn't someone fix the SMTP server instead...?

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-17 Thread Paul Gilmartin
On Tue, 17 Mar 2009 14:39:50 -0400, Tony Harminc wrote:

2009/3/17 Ulrich Krueger:

 At my shop, when I was finally able to pinpoint where the SMTP performance
 problems originated from, I was lucky. A single JCL-procedure was used to
 create the mass-mail file(s). So, instead of sending it directly to
 SYSOUT=(B,SMTP), I added a step to execute a REXX - exec which I had
 written. It split the big file into individual SPOOL files, one per email
 message. Worked like a charm, once I had it all figured out. No more SMTP
 performance problems, no more nasty calls from users.

Shouldn't someone fix the SMTP server instead...?

Would sendmail be better?  If so, it might be time to
replace SMTP, even if only with a spool writer that feeds
sendmail -toi.

Does XMITIP have options to use either sendmail or SMTP?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-17 Thread John McKown
On Tue, 17 Mar 2009 15:18:11 -0500, Paul Gilmartin paulgboul...@aim.com wrote:

On Tue, 17 Mar 2009 14:39:50 -0400, Tony Harminc wrote:

2009/3/17 Ulrich Krueger:

 At my shop, when I was finally able to pinpoint where the SMTP performance
 problems originated from, I was lucky. A single JCL-procedure was used to
 create the mass-mail file(s). So, instead of sending it directly to
 SYSOUT=(B,SMTP), I added a step to execute a REXX - exec which I had
 written. It split the big file into individual SPOOL files, one per email
 message. Worked like a charm, once I had it all figured out. No more SMTP
 performance problems, no more nasty calls from users.

Shouldn't someone fix the SMTP server instead...?

Would sendmail be better?  If so, it might be time to
replace SMTP, even if only with a spool writer that feeds
sendmail -toi.

Does XMITIP have options to use either sendmail or SMTP?

-- gil

XMITIP is an MUA/MTA combination. It formats the message like an MUA, then
transmits like an MTA. XMITIP can transmit to any complaint SMTP server. So,
it is possible to have sendmail running on your z/OS and configure XMITIP to
send to 127.0.0.1 (localhost). This would send the mail to sendmail which
would then relay it out to the appropriate receiving email server.

I don't think that XMITIP can use SMTP. If by SMTP you mean the one which
reads JES output class B with a destination of SMTP.

--
John

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-17 Thread Paul Gilmartin
On Tue, 17 Mar 2009 15:25:06 -0500, John McKown wrote:

Shouldn't someone fix the SMTP server instead...?

Would sendmail be better?  If so, it might be time to
replace SMTP, even if only with a spool writer that feeds
sendmail -toi.

Does XMITIP have options to use either sendmail or SMTP?

-- gil

XMITIP is an MUA/MTA combination. It formats the message like an MUA, then
transmits like an MTA. XMITIP can transmit to any complaint SMTP server. So,
it is possible to have sendmail running on your z/OS and configure XMITIP to
send to 127.0.0.1 (localhost). This would send the mail to sendmail which
would then relay it out to the appropriate receiving email server.

I don't think that XMITIP can use SMTP. If by SMTP you mean the one which
reads JES output class B with a destination of SMTP.

Destination?  or writer?

Oh.  Which universe are we in?  That one, or the one
in which SMTP means RFC 822?  Are you saying that XMITIP
connects directly to Port 25 of the target host?

In the Installation Guide at:

http://www.lbdsoftware.com/XMITIP-Install-Guide.pdf

I find no references to sendmail and numerous to SMTP.  The
most telling is:

  3. Quoting from the z/OS 1.4 Communications Server IP Configuration
 Guide: ?Because SMTP needs authority to create, read, write
 and purge data on the JES spool, any security programs such as
 RACF, protecting JES spool access, must have the SMTP started
 task name in their definitions of authorized users?. Thus you
 may need to have the local security group issue the appropriate
 security commands to allow the SMTP server this access level
 to the spool.

But also:

 Be aware that this document does not tell you how to install
 and configure SMTP on your OS/390 or z/OS system. For that
 you will need to see the IBM documentation. If you are not
 using the host based SMTP server and still want to use this
 package you can by using the provided UDSMTP program
 (documented below).

It sounds as if UDSMTP is the direct Port 25 interface (or perhaps
an interface to sendmail?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


AW: [IBM-MAIN] FW: SYSOUT dynamic allocation in COBOL

2009-03-17 Thread Hartmut Beckmann
Hi,

XMITIP has a new interface to connect directly to the SMTP relay: XMITSOCK. 
But you have to organize the situation that the email can not be delivered 
(define standards for email recovery datasets and an appropriate procedure). 
This is normally / in other cases done for you by the TCPSMTP task which reads 
from spool.

Hartmut



 

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] Im Auftrag von 
Paul Gilmartin
Gesendet: Dienstag, 17. März 2009 23:00
An: IBM-MAIN@bama.ua.edu
Betreff: Re: [IBM-MAIN] FW: SYSOUT dynamic allocation in COBOL

On Tue, 17 Mar 2009 15:25:06 -0500, John McKown wrote:

Shouldn't someone fix the SMTP server instead...?

Would sendmail be better?  If so, it might be time to
replace SMTP, even if only with a spool writer that feeds
sendmail -toi.

Does XMITIP have options to use either sendmail or SMTP?

-- gil

XMITIP is an MUA/MTA combination. It formats the message like an MUA, then
transmits like an MTA. XMITIP can transmit to any complaint SMTP server. So,
it is possible to have sendmail running on your z/OS and configure XMITIP to
send to 127.0.0.1 (localhost). This would send the mail to sendmail which
would then relay it out to the appropriate receiving email server.

I don't think that XMITIP can use SMTP. If by SMTP you mean the one which
reads JES output class B with a destination of SMTP.

Destination?  or writer?

Oh.  Which universe are we in?  That one, or the one
in which SMTP means RFC 822?  Are you saying that XMITIP
connects directly to Port 25 of the target host?

In the Installation Guide at:

http://www.lbdsoftware.com/XMITIP-Install-Guide.pdf

I find no references to sendmail and numerous to SMTP.  The
most telling is:

  3. Quoting from the z/OS 1.4 Communications Server IP Configuration
 Guide: ?Because SMTP needs authority to create, read, write
 and purge data on the JES spool, any security programs such as
 RACF, protecting JES spool access, must have the SMTP started
 task name in their definitions of authorized users?. Thus you
 may need to have the local security group issue the appropriate
 security commands to allow the SMTP server this access level
 to the spool.

But also:

 Be aware that this document does not tell you how to install
 and configure SMTP on your OS/390 or z/OS system. For that
 you will need to see the IBM documentation. If you are not
 using the host based SMTP server and still want to use this
 package you can by using the provided UDSMTP program
 (documented below).

It sounds as if UDSMTP is the direct Port 25 interface (or perhaps
an interface to sendmail?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Atos Origin GmbH, Theodor-Althoff-Straße 47, D-45133 Essen, Postfach 100 123, 
D-45001 Essen
Telefon: +49 201 4305 0, Fax: +49 201 4305 689095, www.atosorigin.de
ING Bank AG, Frankfurt/Main: Konto 001 014 0937, BLZ 500 210 00, Swift / BIC 
INGBDEFF, IBAN DE74 5002 1000 0010 1409 37
Geschäftsführer: Winfried Holz, Handelsregister Essen HRB 19354, Ust.-ID.-Nr.: 
DE147861238


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


FW: SYSOUT dynamic allocation in COBOL

2009-03-16 Thread Bill Klein
I may be missing something, but if you know at compile-time (when you can
set an environment variable) that you want the output to go to SYSOUT, why
are you using files (with OPEN, WRITE, etc) and not just doing a DISPLAY
statement?  Either that or call CEEMSG.

I think those are more normal ways in COBOL to send output to SYSOUT.

David Speake david.spe...@bcbssc.com wrote in message
news:listserv%200903152048381559.0...@bama.ua.edu...
 I have used dynamic allocation via the environmental variables in COBOL.
 Thanks to Steve Comstock and others for getting me started.
 But I see nothing about SYSOUT and it says a DSN is required.
 My need is for a //X DD SYSOUT=(B,SMTP)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-16 Thread Steve Comstock

Bill Klein wrote:

I may be missing something, but if you know at compile-time (when you can
set an environment variable) that you want the output to go to SYSOUT, why
are you using files (with OPEN, WRITE, etc) and not just doing a DISPLAY
statement?  Either that or call CEEMSG.

I think those are more normal ways in COBOL to send output to SYSOUT.

David Speake david.spe...@bcbssc.com wrote in message
news:listserv%200903152048381559.0...@bama.ua.edu...

I have used dynamic allocation via the environmental variables in COBOL.
Thanks to Steve Comstock and others for getting me started.
But I see nothing about SYSOUT and it says a DSN is required.
My need is for a //X DD SYSOUT=(B,SMTP)


Bill,

He's not really sending things to a true SYSOUT file, but to an
email server. However, you could do such a thing by hardcoding
the DD name and opening the file, writing, then closing, and
then re-opening; each file should be sent separately.

Just leave a single DD statement, //MAILOUT  DD  SYSOUT=(B,SMTP)
if you like. No need for dynamic allocation at all.


Don't have time to test right now. I will if I get a chance later.



Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

== Check out the Trainer's Friend Store to purchase z/OS  ==
== application developer toolkits. Sample code in four==
== programming languages, JCL to Assemble or compile, ==
== bind and test. ==
==   http://www.trainersfriend.com/TTFStore/index.html==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-16 Thread Howard Brazee
On 16 Mar 2009 12:06:42 -0700, wmkl...@ix.netcom.com (Bill Klein)
wrote:

I may be missing something, but if you know at compile-time (when you can
set an environment variable) that you want the output to go to SYSOUT, why
are you using files (with OPEN, WRITE, etc) and not just doing a DISPLAY
statement?  Either that or call CEEMSG.

I think those are more normal ways in COBOL to send output to SYSOUT.

They may be more normal, but are they better in any way?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-16 Thread Paul Gilmartin
On Mon, 16 Mar 2009 14:03:59 -0500, Bill Klein wrote:

I may be missing something, but if you know at compile-time (when you can
set an environment variable) that you want the output to go to SYSOUT, why
are you using files (with OPEN, WRITE, etc) and not just doing a DISPLAY
statement?  Either that or call CEEMSG.

I think those are more normal ways in COBOL to send output to SYSOUT.

I don't speak COBOL; bear with me.  What's the syntax, in
the DISPLAY statement, to select which DD SYSOUT in the JCL
is used?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-16 Thread Steve Comstock

Paul Gilmartin wrote:

On Mon, 16 Mar 2009 14:03:59 -0500, Bill Klein wrote:


I may be missing something, but if you know at compile-time (when you can
set an environment variable) that you want the output to go to SYSOUT, why
are you using files (with OPEN, WRITE, etc) and not just doing a DISPLAY
statement?  Either that or call CEEMSG.

I think those are more normal ways in COBOL to send output to SYSOUT.


I don't speak COBOL; bear with me.  What's the syntax, in
the DISPLAY statement, to select which DD SYSOUT in the JCL
is used?

-- gil


DISPLAY ...  UPON {SYSOUT|CONSOLE}

There's a compile time option that can change the DDname
used for UPON SYSOUT, but it is not changeable at run time.



Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

== Check out the Trainer's Friend Store to purchase z/OS  ==
== application developer toolkits. Sample code in four==
== programming languages, JCL to Assemble or compile, ==
== bind and test. ==
==   http://www.trainersfriend.com/TTFStore/index.html==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-16 Thread Tom Marchant
On Mon, 16 Mar 2009 14:03:59 -0500, Bill Klein wrote:

I may be missing something, but if you know at compile-time (when you can
set an environment variable) that you want the output to go to SYSOUT, why
are you using files (with OPEN, WRITE, etc) and not just doing a DISPLAY
statement?  Either that or call CEEMSG.

I think those are more normal ways in COBOL to send output to SYSOUT.

The fact that the output is to be handled in some way by JES (SYSOUT=)
should not be confused with sending the output to DDName SYSOUT.  DISPLAY
always goes to DDName SYSOUT, which can be a data set or a spooled data set
(SYSOUT=x).

The OP has a need for the output to go to a DD that will not contain other
information.  It is not uncommon for a program to have multiple distinct
output data sets, some of which might be handled by the Job Entry Subsystem.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-16 Thread Paul Gilmartin
On Mon, 16 Mar 2009 15:08:48 -0500, Tom Marchant wrote:

On Mon, 16 Mar 2009 14:03:59 -0500, Bill Klein wrote:

I may be missing something, but if you know at compile-time (when you can
set an environment variable) that you want the output to go to SYSOUT, why
are you using files (with OPEN, WRITE, etc) and not just doing a DISPLAY
statement?  Either that or call CEEMSG.

I think those are more normal ways in COBOL to send output to SYSOUT.

The fact that the output is to be handled in some way by JES (SYSOUT=)
should not be confused with sending the output to DDName SYSOUT.  DISPLAY
always goes to DDName SYSOUT, which can be a data set or a spooled data set
(SYSOUT=x).

The OP has a need for the output to go to a DD that will not contain other
information.  It is not uncommon for a program to have multiple distinct
output data sets, some of which might be handled by the Job Entry Subsystem.

The need to send multiple reports to multiple distinct output data
sets, some of which might be handled by the Job Entry Subsystem.
sounds like a strong argument to use OPEN, WRITE, etc in preferende
to more normal ways.

(DDName SYSOUT?  Not SYSPRINT?  Not SYSTERM?  COBOL seems
to want to be the misfit.  Will it accept an alternate DDNAME
list as a second PARM?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: FW: SYSOUT dynamic allocation in COBOL

2009-03-16 Thread Thompson, Steve
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Monday, March 16, 2009 4:01 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: FW: SYSOUT dynamic allocation in COBOL

SNIP 
(DDName SYSOUT?  Not SYSPRINT?  Not SYSTERM?  COBOL seems
to want to be the misfit.  Will it accept an alternate DDNAME
list as a second PARM?)
SNIP

COBOL's original implementation has been carried forward from all the
way back to OS/MFT as far as I know. 

This is why some others pointed out COMPILE time options that can be
set. 

You can only change the SYSOUT DD (well, this was back when I was
dealing with VS/COBOL) via some slick tricks (like an ASM Subroutine
that finds all open DCBs to a particular DD...).

Regards,
Steve Thompson

-- Opinions expressed by this poster may not reflect those of poster's
employer. --

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html