Reporting TPF software bugs to IBM - You think you've got problems?
by Alan Sadowsky

For those of us fortunate enough to have been in the industry for some time, ACP/TPF problem reporting and resolution is a familiar area. Whether on the reporting side, or the resolution side, we've all been a part of the larger picture at one time or another.

Almost every shop has a formal procedure to follow when a problem manifests itself, and for the most part these procedures are very similar, regardless of which shop we're talking about. Generally a problem is reported to a central point of contact (usually the Help Desk), and then "selectively routed" to the appropriate department for ultimate resolution. Selective routing is just another way of saying that a problem is being escalated. Problem escalation is a wonderful option, as long as there is someone to escalate the problem to. Normally the only time your TPF Systems people get involved is when the problem is in the TPF Control Program itself. When it becomes apparent that there is a problem within the operating system software, the buck stops at Systems Programming. If you've ever wondered who the Systems group escalates their problems to, you're about to find out.

Let me first point out one very important fact. In an Online (production) environment, any problems within the operating system software are investigated and fixed by the Systems Programming staff. Unlike other operating systems, IBM does not provide the luxury of direct access to technical assistance for TPF problems. The Systems Programming staff is the first, and last line of defense when confronting the majority of unscheduled TPF outages.

TPF is supported by IBM's Data Systems Division (DSD), in Danbury, Connecticut. DSD serves as the Central Service site for the product, and all TPF development (with the exception of TPFDF) is done at the Danbury lab. The interface to the Customer Support Group at DSD is your local IBM TPF Systems Engineer (SE). When a software problem is identified within the released IBM TPF product, the problem is reported to the local IBM SE. The SE will first search an IBM internal database for problems reported against the customer's release of TPE to determine if the problem has already been reported to DSD by another customer. If the problem has not already been reported, the customer must provide the SE with a detailed analysis of the problem, including symptoms, system errors, console logs, source listings, and in many cases, the software fix that corrected the problem! Only after the SE has concluded that there is in fact a defect in the TPF code, will the SE contact DSD to report the problem. OK, so now you think you know all there is to know about reporting problems to DSD. Well you're wrong Assembler Breath! Here's where the real fun starts.

If DSD accepts the problem from the SE, it will be entered into the "Hotline" database, and assigned to the proper people for resolution. Although it doesn't happen very often, DSD will occasionally "reject" a problem for one of several reasons. For example:

• The problem reported is not a code defect.
• The problem has already been reported .
• The problem cannot be duplicated.
• The situation reported is accurate, however the code is working as designed, and will not be changed.

But I digress. Let's say that DSD has accepted the problem. Depending on the severity assigned to the problem, turnaround time for problem resolution is anywhere from 24 hours to 20 days. In all fairness to IBM, I have to say that DSD is very sensitive to turnaround time, and it should be understood that only those problems with little or no impact on the operation of the customer's system tend to run into the 15-20 day window.

At this point, a "Hotline" problem can become an APAR (Authorized Program Analysis Report). When the problem is finally resolved, it is often made available to the originating customer through his/her local SE. The rest of the TPF world will also get a copy of the fix, when DSD creates and distributes the next PTF tape to the field. PTF (Program Temporary Fix) tapes are usually shipped to the field on a monthly basis, and contain all of the resolved problems that DSD has closed since the previous tape, so all customers can apply the fixes to their systems.

If you've ever seen the Systems staff wandering about aimlessly, and mumbling something about sequence numbers, there's a good chance they've just received a new PTF tape.

In either event, I've spared you the details and particulars on all of the forms and paperwork that must be filled out when a problem is reported. If you do have a genuine interest in the specifics of the process, (they're going to love me for this one), don't hesitate to contact your local IBM TPF SE who call answer your questions.