Re:Release 16.0 APAR's

Discussion created by ca.portal.admin on Oct 18, 2005
Hello All:

A while back there was a discussion and someone mentioned an APAR for
IDMS 16.0 SP2 for ADSOSTAE and also an APAR for an ADSO problem when

Can you send me the APAR numbers please?

I have a site that is receiving a 5105 Abort which is a currency issue
with a KEEP LONGTERM, the Dialog is using a LINK NOSAVE and it just
started failing with the implementation of IDMS 16.0 SP2 in Production.

We have temporarily gotten around this issue by changing the LINK NOSAVE
to a straight LINK.

Bill Allen
This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal and or privileged information. Please contact us immediately if you are not the intended recipients of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed.

IDMS Public Discussion Forum


"Hi Gang, sorry but this is going to be a long one.......

Early in September, I was bringing our production environments up on 16.2 (among ""other"" things - smiles), and was having a few difficulties which weren't uncovered in our testing phase. Needless to say, things were very hectic. Specifically there were 2 seperate problems I was fighting. The first was that PTE's were being corrupted by abending dialogs. The second issue was a nasty little recurring 3970 abend on random CV's.

About a month ago, Chris Wood asked me on the list about HYPER APAR QO71326, and why it was made HYPER. My erroneous response to him, and the list, is pasted at the end of this long apology. Then today, I saw Bill Allen's request for information regarding the ADSOSTAE HYPER APAR, dated 10/12/05. In researching Bill's request, I have found that I made a serious error in my response to Chris, the list, and CA.

The history behind all this:

When we came up on 16.2 there were 2 immediate problems which we encountered. The first was when a dialog abended, it was leaving the PTE terminal type corrupted. Because all of our terminals have an ""AUTOTASK"" value to fire up a menu dialog, the autotask would automatically fire up following an ADS dialog abend, and immediately attempt to write a menu map out to the terminal. This map out operation got a RC=12 because the terminal type in the PTE did not indicate the terminal supported map out operations (it had been corrupted). Following the abend, the autotask would again be reinvoked, only to abend again, over and over. This provided us with reams of task abends on different terminals throughout the day. The problem is, I don't recall if this eventually killed the CV, or not. An APAR was developed to fix this problem in prior releases (we had the test version of this applied to our 14.1 systems, but I no longer have that number), and they are 15.0 - QO71324, 16.0/!
16.1 - QO71325 and 16.2 - QO71326. We applied QO71326 and the problem was resolved. When I spoke with CA about another problem (I'll explain in a minute), I mistakenly told them it was THIS APAR that should be made HYPER since it crashed our CV (and at this point, I know the problem was VERY severe, but don't recall if it actually caused a crash, or not). CA went ahead and made the APAR hyper at my erroneous request because I confused this APAR with the one that fixed the 3970 abends (another problem).


We started experiencing random 3970 abends. It was this problem where we found that the ADSOSTAE module had a bug, and when given control, would crash the CV - IE. after an ADS dialog abend, followed by a run time system abend for the task. We found out there was a published APAR in 15.0 (QO72182) that addressed this problem, and CA floated this APAR to 16.2 for us as TC18338 (yet to be published for 16.2). This fixed this particular problem. THIS is the APAR that SHOULD have been made HYPER, since I am SURE it was the cause of at least 7 3970 abends over the course of 2 days.

In summary:

1.) I think I screwed up and I apologize to Chris, the list, and CA for the erroneous information I have provided. There are 2 seperate and distinct issues here, with 2 seperate and distinct solutions, neither of which I have posted correctly.
3.) CA marked the wrong APAR as HYPER, per my erroneous request.
2.) If you are 16.2, apply APAR's TC18338 (ADSOSTAE and 3970 problem) and QO71326 (corrupt PTE on ADS dialog abend). We are now VERY stable with these 2 APAR's applied.
3.) If you are 15,0, apply APAR's QO72182 (ADSOSTAE and 3970 problem) and QO71324 (corrupt PTE on ADS dialog abend).
4.) If you are 16.0/16.1, apply APAR QO71325 (corrupt PTE on ADS dialog abend), and then request CA to float TC18338 (or the 15.0 version QO72182) to SP0/SP1 for you, then apply it (ADSOSTAE and 3970 problem).

I apologize for any confusion and/or inconvenience my mistake may have caused any of you, and to CA for the mixup in marking the wrong APAR as HYPER (although I'm not sure it should be changed since the problem it addresses IS severe). In short, TC18338 fixes the 3970 problems in 16.2, and is serious.

You may now proceed with the tar and feathering.........but ensure you have these APAR's on first (smiles).

Rikki Kirschner
(517) 347-5772

Chris's post dated 09/14/05:

""What about these apars make them hyper? Without them what could happen
to a CV?""


My Response dated 09/20/05:

""Hi Chris. I am the one that requested this be made a HYPER. We had a 14.1 version of the test fix on our systems for years. When we went to 16.2 last month, we started having problems again (as we did when we first came up on 14.1) with 3970 abends. I had forgotten about this test fix that was on our 14.1 systems, and had not gotten the 16.2 version of the fix and applied it. When I called in the 3970 (before I remembered the old 14.1 problem), level 1 poitely reminded me of the fix, and the problem. I asked for a 16.2 version of the 14.1 test fix, and why it had not been published. I was told that they had planned to source the test fix in, but had neglected to do so (oversight). They floated the test fix to 16.2 and gave it to me. Apparently, they also made a published version of the fix for 15.0 and 16.0/16.1. It was at that point that I said I thought it should be made a HYPER since not applying it can result in 3970 abends under certain circumstances.
A better description of the problem is that an ADS dialog abends due to a storage violation (we do have HPSP turned on in Production, and it did NOT catch the violation, which I would presume to be localized to the user task since it was not caught by Storage Protect). The ADS run time system abends and the ADSOSTAE routine gets control, and abends again. The system determines this to be a recursive abend, and takes down the CV on the 3970.
This patch allows the user task to abend, the ADS run time system to abend (for the user) and the ADSOSTAE routine to complete without killing the CV.
If memory serves me correctly, we had 3 CV crashes one day, then 4 the next, until I got the PTF applied. We haven't crashed again since. Also, we have the programmers working on the dialogs to try and find/fix the original problem(s).
Hope this helps explain why it ended up as a HYPER.
QO71324 - 15.0
QO71325 - 16.0/16.1
QO71326 - 16.2
Rikki Kirschner
(517) 347-5772""

IDMS Public Discussion Forum



Thanks for the long explanation about your ADSOSTAE problems.

It is because of people like you that this list has the tremendous
effect on IDMS that is has. We are all willing to share our experiences
so that others can avoid the pitfalls. My site is able to be pro-active
because of yours and other's contributions.

I can only remember HYPER's coming out now because of bad apar's being
released. Like most shops nowadays we have to be aware of security and
other situations that could bring our systems down and lead to possibly
lengthy recoveries. For these reasons I was interested when your apar
came out as HYPER. Here, at DOE, we did not think that it sounded like
something that should be hyper and we are just starting to test it out.
If we experience any of the 3970 abends then we will definitely be
looking for TC18338 or backing it out. 16.0 is in a freeze for SP3

I would love to meet as many as possible in Vegas in November but I
leave there on Nov 10th after attending the MS SQL Connections
Conference, with my copy of SQL2005, rather than CA-WORLD.