It was a specific selection of group PTFs (I can list them). I know the 127 PTFs that were applied but we've been unable to determine which PTF(s) are at fault (or if IBM fixed a bug and really our vendor does have a bug in their process). The vendor took the feeback from IBM and is looking at their code. The problem is the feedback is in regards to what they are doing with commitment control on their logging and not what is happening with the RPG code and locks. It could very well be related but based on the speed with which things have been moving, I just want my production environment fixed.
I do have a test environment that did not originally show the issue, but it did start having the same issue over time (4 days later). It doesn't get used near as much as production so that might explain the delay in seeing the issue.
I specifically asked IBM for their recommendations on rolling these back (they have the whole list of PTFs applied and the groups from which I got them. Side step/send us more logs/you're not collecting the logs correctly/oh, yes you are collecting the logs correctly/add these PTFs/send us more logs/uhm we think it's your vendor, look at the commitment control on the logging file...
Have a debit card conversion this weekend, and building our review banks next week, so it'll be another week before I can muck with our test environment and test unrolling on my own. I can hope someone has something by then but I'm doubting it. Vendor has another customer with the same issue immediately after putting in a Power 9 on 7/20 and I was the second reported problem on 7/29.
Coy Krill
Core Processing Team Lead
Washington Trust Bank
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Jack Kingsley
Sent: Wednesday, August 14, 2019 02:25
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: PTF Rollback Ideas
Importance: Low
You don't mention what type of PTF's that they were, cume, groups, etc.
Have you been able to narrow it down or not really based on your number of 127. Did you apply these to any lower environments first and test with them, did you see the same results. You also didn't mention what the vendor is doing about the problem. In the article below they don't mention using RMVPTF.
There is this if it helps.
https://www-01.ibm.com/support/docview.wss?uid=nas8N1014960
On Tue, Aug 13, 2019 at 7:52 PM Krill, Coy <CKrill@xxxxxxxxxxx> wrote:
Recently made the mistake of applying some PTFs that had not yet been
vetted by our vendor (I'm, lucky if they vet a CUME per year these
days) and have now had two weeks of production impact with what
appears to be slow record lock releases. I'm in limbo between IBM and
my vendor at the moment as IBM has now decided it's probably an issue
in the vendors code, however, they keep focusing on some SQL action
that isn't part of the problem. The problem is two RPG programs where
program 1 updates a record and then calls the next program to do another update to the same record.
This worked fine until I loaded some group PTFs.
All that preamble to get to my question. I want to roll these off.
It's been probably 20+ years since I've had to back off PTFs and never
about 127 of them to roll it all back. Is there any kind of automated
way of determining the right/best sequence for unrolling them? Anybody
had to do this in recent years?
Coy Krill
Core Processing Team Lead
Washington Trust Bank
This electronic mail message and any attachments may contain
confidential or privileged information and is intended for use solely
by the above-referenced recipient. Any review, copying, printing,
disclosure, distribution, or other use by any other person or entity
is strictly prohibited under applicable law. If you are not the named
recipient, or believe you have received this message in error, please
immediately notify the sender by replying to this message and delete
the copy you received
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
This electronic mail message and any attachments may contain confidential or privileged information and is intended for use solely by the above-referenced recipient. Any review, copying, printing, disclosure, distribution, or other use by any other person or entity is strictly prohibited under applicable law. If you are not the named recipient, or believe you have received this message in error, please immediately notify the sender by replying to this message and delete the copy you received
midrange.com
