On Nov 17, 2007, at 11:05 PM, Joel C. Ewing wrote:
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.
Joel,
Interesting. I guess that works in your environment. In the
environments I have worked in there is too much political stuff going
on and the finger pointing gets rather well pointed. (sorry about the
pun).
I have always worked in environments that the production control is
separate and distinct from support. No programmers (unless they got
paid for OT) wants to be called at 0000 to handle space abends and
the like so production support is always there to handle mundane
issues. As a side issue most of the time that I have seen the day to
day issues are really better handled by production control people.
There are some exceptions of course but most of the time the
documentation turned over at turnover time is really gone through
with a fine tooth comb and acceptance only occurs when the people who
will be handling the jobstream are comfortable with it. That is NOT
to say they are right 100 percent of the time but pretty close and
the few percent they aren't is because of either a rare fluke or the
doc was in error (most likely cause).
Point taken on the DB2 issue (or other DB issues) there probably
isn't a schedular package in the world that can handle those.
Also, I have never worked in an environment where (except for
extremely minor programs) TS has written essentially application
code. The one exception I can think of was 30+ years ago where there
was a database and a program was written so that the applications
people could call the code for read/write access to the database.
There was (I think) never any issue of issues because it was
extremely simple interface and handled errors quite well. In the
several years I was there I don't recall a error ever happening in
that code. I wrote a few utility type programs but those were more of
conversion type programs where applications types never saw the code.
The operators were in a sense my end users for those programs.
I have written exits and such where the application types doesn't
invoke them per se but is on the receiving end of their submissions.
So I supported them but in a semi passive way. AFAIK none of my code
has ever broken. The exits may have had to be recompiled or changed
because IBM does change parameter lists or macros change or JES changes.
None of the places I have ever worked do not allow products to be put
in a production jobstream unless there is 24x7 support from the
vendor PERIOD and only then under a really stringent set of "ifs".
I have worked on both sides of the Atlantic and programmers in the
states are somewhat more accepting of midnight calls (exceptions
exist), so it may well be the area you are from that make exceptions
to the normals.
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
