On Nov 17, 2007, at 12:15 AM, Joel C. Ewing wrote:
I've always assumed there was slightly less overhead in running
batch REXX without the TSO TMP, provided you didn't need any TSO
commands or ISPF services - but I suspect this overhead is
minimal. I believe you also avoid the need for several DDs, which
in a bizarre case might make a difference.
We regularly run batch TSO (batch TMP), batch REXX, and batch ISPF
from production batch jobs, which all run under userids with no TSO
access (No TSO Segment and not in SYSUADS).
I can't conceive of any rational reason why a sysadmin or auditor
would want to restrict batch TMP usage. It buys you no power or
data access that could not be derived by other means, except
perhaps for the somewhat dubious ability to execute CLISTs - but
everything a CLIST can do can be better done by REXX.
Joel:
Interesting idea about not restricting TMP usage in batch. One reason
(amongst others) is that debugging is hard (if not impossible) to do
after an issue. Of course its one thing in a testing environment but
in a production environment? I just can't see production support
people supporting such an environment. Their job is difficult enough
with JCL and typical abends but to throw in TMP (non abends usually)
issue is just an environment that most support people would run away
from and refuse to have any responsibility over.
While it might be possible, I have seen most support people say "NO"
to TMP issues (bugs whatever). Trying to get a scheduling package to
handle issues in that environment would probably be almost impossible.
Ed
----------------------------------------------------------------------
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
