Oppolzer - Informatik / Blog

In our environment, the Test PUTs are controlled by a global switch
on the module start macro. Some people (including myself) control the
position of this switch using a compile time option (compiler job control),
others don't. But in any case: when preparing the program for transport into
production, this switch has to be off, and the system doing the transport
(home grown) checks the setting of this switch by examining the load module
and refuses to transport the load module - at least there is a warning to
the admins, if the switch is set, so that the admins can stop the transport.

Same reason for doing this: it is unacceptable to have the IMS dialogs
or logfiles flooded with debugging messages. Most developers put their
module names in front of the message, so that it is clear where the
messages comes from, but it is not acceptable, anyway.

With C modules, we had the messages on the display terminals
sometimes, because C modules allocated stdout to SYS00001,
if SYSPRINT was already opened by a PL/1 module started earlier.

Kind regards

Bernd



Am Mittwoch, 7. März 2012 08:56 schrieben Sie:
>
> Your use of STREAM only for testing is not uncommon.  The
> issue we used to see was when the PUTs were not removed from
> the program as they were supposed to be.  Thus, the EPA has
> an External Analyzer that searches all load modules to find
> any use of STREAM I/O.  This tool came about when one of
> our users discovered some of those debugging comments being
> generated in production CICS/IMS regions, but could not
> identify which of the thousands of transactions had the PUTs
> still in the code.  It caused a real problem when the PUTs
> created enough messages to fill up the output queue.  Of
> course, no one would own up to, "Oh, I guess that may have
> been my program..."
>
> C.
>