Let me guess, they still didn't bother to add a test for
table-size-exceeded to perform a "graceful failure" of the transaction
rather than take out the entire CICS region when the increased table
eventually proves inadequate; and if just increasing max table sizes
greatly increased CPU, then no doubt they are doing an inefficient
search of the tables or always initializing the entire table
unnecessarily rather than just those entries actually used. Perhaps the
transaction is doing a serial search of entries in the table, which
while tolerable for 10 entries is a bad idea for 33 entries and a
terrible one for 99. Or they could even be doing something worse, like
initially clearing the entire table and searching the entire table
serially even when only a subset has been used.
Transaction algorithm redesign to reduce maximum memory required by
tables is probably not trivial, so throwing hardware memory at that
could well be cost-effective and make a lot of sense. Failing to expend
coding effort to check for table overflow and thereby risking loss of an
entire production CICS and down time is definitely false economy, and
developers should be required to always make explicit tests for table
overflow. I would think it would only take a minor amount of time to
examine the code to look for an inefficient table search or unnecessary
table initialization, and if the tables are growing with time the
potential long-term payoff in saved CPU time and better transaction
performance from fixing any problems in that area should be well worth
the effort.
Our Technical Services had metrics in place and published daily
statistics available to both application areas, IT management, and end
users which showed among other things the "top" CICS transaction and
application contenders for total resource usage and per transaction
resource usage and response time. It was obvious when changes suddenly
raised the costs unexpectedly in ways that adversely affected the system
as a whole or critical applications. Pressure from end users (who
didn't want to see their proportion of computing costs increase) and
other application areas (who didn't want to be adversely affected by
other resource hogs), and management backing made it relatively easy for
Technical Services to get application code performance reviews in such
cases.
Since such issues in a production environment were also regarded as a
"system problem", it was not uncommon for our application programmers to
work hand-in hand with TechSys CICS support perusing code to find quick
fixes where that was possible, and suggest back out and possible
redesign approaches where there was no easy fix.
Wise management should understand that expending a few hours looking for
trivial performance tuning in mainframe applications that are seeing a
performance problem is always cheaper than a mainframe upgrade.
Mainframe environments typically have the tools to make such analysis
feasible. And, if some trivial change does indeed resolve the problem,
this is also an opportunity to further educate Applications development
staff so they know what techniques to avoid in the future.
Joel C. Ewing
On 04/04/2015 04:11 PM, Blaicher, Christopher Y. wrote:
> Please send us the name of the company. First, so the IBM sales person can
> get right over there and make a nice commission, and secondly, so I can sell
> any stock I may have in the company.
>
> If they have management that is that ill-informed and, well frankly, stupid
> (I tried to not use that word, but in this case it fits), then it doesn't
> speak well for the long-term survival of the company.
>
> Personal opinion only.
>
> Chris Blaicher
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of Roger W. Suhr (GMail)
> Sent: Saturday, April 04, 2015 4:46 PM
> To: [email protected]
> Subject: Re: A New Perfromance Model ?
>
> On 4/4/2015 3:11 PM, [email protected] wrote:
>> Hi
>>
>> Im not a performance analyst, Im a CICS & MQ Sys-Prog.
>> I dont understand this new "paradyne".
>>
>> Some Back ground
>> March 1 Our Development Team introducd some new functionality.
>> The following week we were plagued with multiple 0C4 and 0C7 - ASRA Abends,
>> Storage Violations, and one CICS Task abended in a loss of our main
>> production CICS Region.
>>
>> March 7 a secnd wave of application changes were deployed.
>> All Of the Abends with the Exception of The Storage Vioation seem to
>> have evaporated, as they no-longer exists. However we are now see a
>> sihnificant Increase of I/O, Almost double in CPU consumption by many tasks,
>> and an Increase in Storage Occupancy for these transaction.
>>
>> Some Transaction Storage incresaed by 6+ Meg.
>>
>> Working with our Capacity Planning and Performance person and
>> reviewing CMF data, RMF Reports, running Traces, and real time Monitors we
>> have identified the 7 buggest cuprits. (STROBE is a Great Product) .
>> We provided our findings and analysis to our Management and Mainframe
>> development management with much reluctance.
>> .
>> .
>>
>> Heres what I dont understand
>> Our development management are telling is (Systems & Operations) that it is
>> "cheaper to Upgrade the mainfame than to have the application programmers
>> review their code for performance oppurtunities".
>> .
>> .
>> Are You F...ing kidding me.
>> .
>> .
>> In todays era is this true, because I havent heard of it ?
>> .
>> The Systems teams spent three weeks trying to compensate and adjust our
>> performance configuration (LPAR Weights, CICS File Adjustments etc.) to
>> accomodate the additional CPU that was introduced.
>> .
>> I have not seen any documents produced stating that it would be cheaper to
>> Upgrade to a larger machine. What about the License costs for all our
>> products ?
>> .
>> .
>> If a Machine costs 8 Million, are you telling me 10 good COBOL CICS &
>> MQ appliaction programmers could not make some improvement for less than
>> 8-Mil ?
>> .
>> One of My application developers explained to me that they were getting a
>> ASRA/0C4 Abend.
>> So to correct it they increased 3 tables from 33 entries (3Meg) to 99
>> entries (9Meg).
>> .
>> Did I miss a performance lecture at SHARE ?
>> .
>> Can someone explain and rationalize for this new paradyne ?
>> .
>> "cheaper to Upgrade the mainfame than to have the application programmers
>> review their code for performance oppurtunities".
>>
>> .
>> Im clueless . ??
>>
...
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
