> I disagree, Ed. Reading a list of
> destinations from a "parmlib"-type dataset can be the
> easiest, and best way, to handle this situation. But updates
> to this dataset should be controled and audited, just like a
> PROCLIB or any other control-related library. Make provision
> for comments in the destination list and it doesn't have to
> degenerate into a boar's nest, nor does it need to be so
> specialized that nobody can understand it.
>
> IIRC, the DYNAM subroutine from the CBTTAPE site has
> provisions for the appropriate SYSOUT dynamic allocation,
> and FREE=CLOSE can save a DYNAM call.
>
> -- Rick
-----SNIP--------------
Rick:
Yes you can do that I didn't say you couldn't the issue is (albeit a side issue
and important IMO none the less) associating the contents back to the step that
is using it *AND* if you then move it out of lets say proclib for discussion
here, there is and always will be "oops" I forgot that this had to be updated.
Plus you have the side issue of "when" the change occurs. usually its another
department that handles the update so scheduling it is a matter of what can go
wrong will go wrong. I am a pessimist and I have rarely seen it where
departments can actually depend on an update to occur when it should. This is
not to say "your" installation is better but more times than not it doesn't
happen.
There is also another side issue I have experienced myself. in the it is
extremely common to search proclib for a dest=xxxx (for production and non
production) chances are with your way moving it to parmlib type dataset this
scan will miss the destination you are looking for.
IMO it is a deep dark hole to dig. Do it right and put it in the JCL (Proclib)
and everyone will be happy and you may gain a night or two of extra sleep with
not having to worry about it at 3AM or so . Its done wonders for my sleep.
Ed
ps: You can set up the JCL for dummy (default) so unless the dd is overridden
it won't go anywhere except the bit bucket:)
from a sketchy memory //sysout99 dd dummy.sysout=a,dest=newyork
If you set up your proc default to dummy=dummy then the report will be written
to but never created. then all you have to have is an override at execution
time to "undummy" the dd card. That is the safest, IMO.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
