Ed Gould wrote:
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
...
Ed,
I gather from remarks I have heard at SHARE and elsewhere that our data
processing environment may be rather unique - one reason why I have
stayed here for almost 30 years. Our environment is very non-Dilbert.
At least within the data-processing subsidiary, managers are not PHB
Business majors, but have Information Processing backgrounds and have
come up through the ranks and understand the technical side of of the
data processing business. There has been a tradition here of investing
more in people and less in hardware, and that is reflected in a lower
turn-over rate than is typical in the industry. All management positions
are filled by promotion from within.
We don't have programmers, we have Systems Analysts/Programmers. Their
job description is not just to implement applications, but to work
directly with the various corporate departments, help them determine
what they need to support their customers, design application specs,
implement the application, and support, improve, and maintain the
resulting applications. A significant part of their knowledge base
involves understanding the processes and problems of the corporate
department they support.
It may sound trite, but I really believe the majority of our SA/P's are
quite conscious that their function is not to produce software
applications but to support the ability of the corporation to function
and to support our corporate customers, who are the ultimate source of
all revenue. Those SA/Ps doing application development deal directly
with those in the corporate departments they support, and if there are
processing problems that aren't being addressed, they are the ones that
ultimately get involved in finding a solution. Here the foreign concept
would be NOT getting those most experienced with the application
involved in resolving a night production problem which could result in
some critical online application being delayed the next day. While no
one likes getting a 3 AM call, we like even less having to explain to
our users that some critical system is down because the right person
wasn't called and the fix either took too long or a wrong fix caused
additional problems. We have an On-Call application (written by
Technical Services) that implements a rotation for off-hours calls and
tracks who is on call for batch job streams, on-line applications, and
various Technical Service support (for generic system or vendor product
problems, or if the SA/Ps encounter something for which they just need
our help). It is required that even on holidays there be someone
reachable, at least for remote support, in the event of a application or
system problem. The Operations staff will attempt to resolve a limited
number of DD space problems and step restarts caused by tape drive
failures, provided the job step is documented as restartable, but beyond
that the application people will generally get involved (unless the job
really is non-critical, in which case it will be marked in the on-call
system as "no night call").
Technical Services here has traditionally been a multi-faceted job,
doing some things that would probably be impossible in a place like
Chicago or NYC where having a non-union person do a "union job" can
result in problems with the unions. In the first decade I was here we
did whatever was necessary to support the hardware end of DP and
minimize the time for hardware changes: install connectors on power
cables and make connections to equipment and live breaker boxes in the
computer room; run and connect channel cables and EPO cables under the
raised floor; design and install runs of coax and telco 25-pair cables
(for data communications lines) within multiple buildings owned by the
corporation or in buildings owned by customers, including runs across
alleys, under floors, in ceiling crawl spaces, through 1 foot concrete
walls, between floors, etc.; physically transport and install 3270
devices, remote 3276 controllers, 3174 controllers, and install modems
at various sites; design, build, and install coax interface cabinets
(involved welding); design computer room equipment layouts and
physically cut the required openings in the steel-reinforced floor
tiles; and assist IBM in the physical installation of equipment. Our
Director of Technical Services was directly involved in many of these
activities as well, and the tradition of a hands-on Director who is not
above physical labor when we are under time constraints has persisted
through multiple Directors up to today. We no longer do routine
communications cabling, or power cabling, but mostly just because we
lack the time. However, the corporate data communications wiring
systems are still designed by the Network sub-section of Technical
Services, and they still handle all data communications wiring in the
computer room and in the distribution closets.
There is also a long standing tradition here of significant software
development under Technical Services. When I first came here (1978, in
Itel-DOS/VS, pre-CICS days), all on-line programs ran in a multi-tasking
online partition in a MiniTask subsystem written by the then Director of
Technical Services, who also used that as a platform to implement an
On-Line-Editor application (OLE'), which was a 3270 application used for
almost all application development and test batch submission. The same
Director also designed and wrote the communications programs that ran on
a System/1 to drive what was then our corporate communications network.
Over the years Technical Services has designed and implemented (and
supported) a number of minor utilities and some fairly major ones: A
disk-based interlock/enqueuing system using channel programming to
permit controlled updates to shared libraries by two Itel DOS/VS
systems; a source library system for DOS/VS to address many shortcomings
of native DOS/VS source libraries; several versions of compile dialogs,
which are now used for all MVS compiles to insure that all applications
development usage invokes the various compilers/assemblers with correct
options and uses library families in accordance with corporate
standards; several versions of a Library Management System, which
handles promotion of application code into protected production
libraries, with auditing; a CICS function-based security system; ISPF
applications to make various requests to Operations for production job
changes. In many cases, if Technical Services sees a generic need,
especially one that crosses application areas or that requires the
expertise of Technical Services to implement, we are given the
flexibility to implement a solution. Also, one of the roles of
Technical Services is to address issues or problems facing our
Operations staff. If our Operations department should have a processing
need, Technical Services is their default programming development
support - appropriate because their problems typically involve
interfaces to either the Operating System or to vendor products, both
our area of expertise.
While all our 3rd party vendor products have 24x7 support, in our
experience in recent years that support would be of much less use to
someone who hasn't dealt with the product enough to understand enough of
the internals and enough of the vendors product terminology to discuss
and argue the problem intelligently with the vendor. If a "new" problem
with a product is found, it is not unusual for it to take much
documentation and effort to get past the vendor's level-1-support or WAD
denials. Using the same philosophy as for application code problems, we
funnel all suspected vendor problems through those most familiar with
its installation and customization: the section of Technical Services
that installed the product. This way we can weed out all "obvious"
usage/configuration problems, possibly find a simple circumvention
without waiting on a vendor response, and if vendor contact is required,
insure we have a single contact point with the vendor.
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
Sr Mainframe Admin, Mainframe Systems, Data-Tronics Corp.
----------------------------------------------------------------------
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
