We don't turn REXX or batch TMP loose as a general tool for Applications
development to write code for production batch, but batch REXX,
including batch REXX that runs in batch TSO or batch ISPF environments,
has been frequently used by Technical Services to quickly implement a
number of simple utilities needed by Applications Development. These
utilities are documented and made available to application programming
for use in production batch, and if they break, Tech Services does the
debugging. We have not found any significant problems in using batch
TMP in this way, as properly disciplined REXX code can be restartable,
can check for internal failures and reflect failures back to the step
completion code if necessary, and issues with a job scheduler or job
restart software can be avoided. In many cases these utilities that run
under TMP may actually do a better job of providing meaningful
diagnostic messages than if implemented in some other way - it seems to
take much less effort to provide meaningful text diagnostic messages in
REXX, so it's more likely they will be implemented.
Before programmers started using the DB2 Call Attach Facility (CAF) to
handle the connect to the appropriate DB2 subsystem, the only way to
execute a program using DB2 in batch was to run it under the TSO DSN
Command processor under TMP in batch TSO. As long as the application
program was implemented in a high level language with a runtime
environment that provides reasonable debugging information, the fact
that the runtime environment is under TMP really did not have any
significant impact on difficulty of problem resolution.
One thing which may make this practical in our environment which I
gather may not be true in yours - our production support people are the
same people who do application development. We find receiving 0300
problem calls provides strong incentive to Applications Development (and
to Technical Services) to design things for reasonable diagnostics and
restartability, and to promptly resolve any deficiencies in those areas.
Ed Gould wrote:
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
...
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
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
