APAR = Authorized (Authorised for the rest of the world) Program Analysis 
Report or Record
PTF = Program Temporary Fix

Source:  http://www-01.ibm.com/software/support/docdefs.html
Also supported by:  http://www.comlay.net/ibmjarg.pdf  and my 21+ years of 
coding fixes at IBM.

The following is not necessarily the language used by all IBM service personnel 
at all sites, but it's what was in use in Poughkeepsie when I left in '07:

PMR/ETR - a customer report of an issue, essentially "Hey IBM, something seems 
to be wrong."
PMR is a Problem Management Request 
(http://www-01.ibm.com/support/docview.wss?uid=swg21507643)
ETR is Electronic Technical Response - really the name of the tool (which has 
been replaced by SR) but became the internal jargon for "a problem opened 
electronically through the tool, rather than the customer calling into level 
1."  

PMRs could be converted to ETRs by customer request or consent.  "Would it be 
ok to convert this to electronic?" was frequently intoned by level two folks, 
because you didn't actually have to contact the customer after "dispatching to" 
(taking ownership of) the call (PMR) on RETAIN, eliminating the metric of "time 
between dispatch and contact."

When the level 2 engineer was temporarily done working on a PMR, they would set 
a time to follow-up ("FUP") on the problem, which would cause the problem to 
return to that engineer's problem queue if nothing has happened in the interim 
(e.g. still waiting for customer documentation).  For non-electronic PMRs, when 
a customer was unavailable, the level 2 engineer might frequently dispatch to a 
problem, try to call the customer, get to voice mail and update the PMR with 
"NILM" (Not In, Left Message).

When it is decided that a PMR has actually exposed a legitimate problem in the 
product (a defect), an APAR is "taken" (created/written).  Problems that are 
closed and do not result in APARs are categorized as NDOPs (Non-Defect Oriented 
Problems).

Not all APARs cause fixes to be coded.  IBM measures and attempts to maximize 
the number of problems closed without fixes (FIN, SUG, et al, discussed ad 
nauseum on this list).  It is not entirely a "work avoidance" initiative.  Many 
problems are easily avoided or are of little to no impact; issuing fixes for 
these increases the risk of destabilizing the product (or other dependent 
products).  The only sure way to zero PEs (PTFs in Error) is to ship zero PTFs, 
right?

If a fix is to be made, it is assigned to someone in "level 3" or "the Change 
Team."  In the old days, level 1, 2, and 3 were separated from development by 
an IBM divisional boundary.  There were actual negotiations as to how much 
internal money was transferred from the development budget to the support 
budget based on the size and complexity of the releases.  I recall that this 
ended and support joined the same division with the release of MVS 4.1; due to 
the size and scope of the changes (ESCON, Sysplex, ....) the calculated budget 
was astronomical, so they just transferred all of the support center into DSD 
(the now defunct Data Systems Division).

The engineer responsible for fixing the problem may wish to try a preliminary 
version of the fix out with a willing customer.  This kind of fix is called a 
++APAR (say, "plus plus APAR") based on the SMP/E keyword that defines the 
deliverable.  The engineer may iterate over various versions of the fix by 
changing the name (AA12345, AB12345, AC12345...) or updating the rework date.  
When the fix has been sufficiently tested, the engineer closes the APAR and 
generates PTFs (usually one per release where a fix is shipped).

Closing the PTF does not necessarily close the call.  Generally, level 2 will 
close the loop with the customer(s) who have discovered the problem and are 
likely waiting for the fix.

I'm sure those of you on the customer side have a different view of things...  

Scott Fagen
Mainframe Chief Architect 
CA Technologies


On Fri, 17 Aug 2012 13:02:43 -0400, Shmuel Metz (Seymour J.) 
<[email protected]> wrote:
>In <[email protected]>, on 08/16/2012
>   at 10:13 PM, "R.S." <[email protected]> said:
>
>>BTW: PTF name is misleading. It stands for Program *Temporary* Fix,
>
>Product.
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to