How do you handle Mega patches?

Good Morning

In the last couple months, our users have experienced application errors that require patches – one in Payroll and one in Procurement. Support identified patches that need to be applied. In order to assess the testing effort involved, I used lawappinstall preview to determine the number of programs functionally changed. Each patch changes +800 programs. Obviously, each of these patches will trigger a huge testing effort. When questioned, Support is insistent that there are no other patches that will correct these errors.

Have others experienced this seeming change to support services where mega patches are the answer to most application errors? If so, do you just live with the errors until your organization is able to schedule a full round of testing, or do you just roll the dice and apply the patch?

Appinstallanalysis preview started at 12/27/2016 10:35:26 for the following deliverables: PATCH114170.preview.

Analysis Summary:

Total Source Files Changed: 274

Programs Affected: 1063

Programs Compiled: 957

Programs Functionality Changed: 868

Programs that Call Changed Programs: 694

Called Programs with Changes: 40

Appinstallanalysis preview started at 02/06/2017 16:24:25 for the following deliverables: PATCH112181.preview.

Analysis Summary:

Total Source Files Changed: 108

Programs Affected: 1169

Programs Compiled: 901

Programs Functionality Changed: 865

Programs that Call Changed Programs: 379

Called Programs with Changes: 17

Find more posts tagged with

Infor Lawson Technology Group - Discussion

Comments

jreese

Mega patches are nothing new. The problem is the longer you wait between applying MSP's the worse they can get. If the patch is critical enough then we do apply it but do attempt to get all associated programs that are compiled with the fix tested, along with the fix, prior to moving it to Production. At the bottom of Preview, there is a list of the compiled programs. In most cases, we don't use all the programs listed so the testing effort isn't as bad as it appears.

unknown

I am now on my new company and was not able to bring my docs with me to share. However, this is how I remember doing it.

- Before you apply the patch, search for *.err on the source codes parent folder and screen shot.

- Apply the patch.

- Once it is completed, beware it is not really completed.

- Run qstatus to make sure its queue is empty. If not wait and rerun until all the jobs are done.

- Do another search for *.err. If there new ones, stop and DO NOT PROCEEED. Fix them first.

- Repeat.

Jude

unknown

We evaluate each patch to determine what is affected. If it is a small number of programs then we will go ahead and apply it. If it is a large number then we will determine if a work around can be used and will wait. If no work around is available we will test the programs that we use. The users will complain, but they would complain more if proper testing wasn't done and we had a situation that caused problems with the data or the system being down. Because Lawson breaks down there Cobol programs into modules so that the code can be used by several programs one change can affect many programs.

unknown

Hi! You've brought back for me a combination of repressed horrible patch memories and current ones too!! In the past couple years we've noticed this situation and have been incredibly discouraged and disgusted. Here are some bullet points on the topic and our experience:

- We noticed this beginning early last year when, just after we upgraded to v10, users were experiencing an issue with an HR511 conversion program. We were given a patch number by Support. Found it and, to fix this one minor program issue was going to require testing of around 1000 programs along with dbreorgs that would add all sorts of Middle East tables. We complained to our Account Exec and worked with Development so that they simplified it down some - but not much. Due to the urgency, we had to bite the bullet and put the patch in and all the testing was done.

- Because of this situation, our users, in my experience, are experiencing major 'testing fatigue'.

- Our approach now: Whether or not we put a patch like this in depends solely on the urgency. And, if it must be put in, all the testing must be done.

- We met with Application Development management a couple months ago and outlined this issue along with others. They said they're aware of and working on improving this.

- To attempt to get ahead of this, for our first maintenance cycle of 2017, we put in over 700 CTP's so that we could get totally caught up on everything and, hopefully, avoid this sort of thing. We're cautiously hopeful but, since each week there are, literally, dozens of new patches, we wonder(!!).

Sorry for the length of this. Just want you to know that you're not alone.

Let me know if you have questions,

Lenny

unknown

Oh, and one more thing: For one of the megapatches that was needed to fix an issue recently (a PR program), we asked for just the PR program fix and, in this case, and was given the specific 'piece' of the patch that fixed the one program. It was a minor fix so easy to 'separate out'. So it doesn't hurt to at least ask the question.

akuhl

Lenny, would you mind telling me what PR and HR511 issue you discovered after moving to v10? We've are in the final stages of testing our v10 upgrade and want to make sure I didn't miss something.

thanks, Karen

plancor

Thank you, courcl. What you have outlined are exactly the frustrations we are experiencing. Previously, it was usually possible to get a patch that only touched maybe a dozen programs, but (it seems to me) recently the only answer is these mega patches. Our users have jobs to do - and they weren't hired to test Infor products.

I also contacted our Account Exec and got no where. I think if we, as a group, put pressure on Infor, we "may" stand a chance of receiving better solutions to patch applications.

unknown

Well INFOR on their first conference talked about speed and making changes fast but they forgot to test. So I believe the customer has become their testing power. We are healthcare and it is hard to do testing that we are use to with some of these mega patches INFOR tells you to apply. Yes you are right they will not just give you correction for your error.

Hans Mueller

Hi all -

This is nothing new and the global user group tackled this many years ago and that is how the AMT (application maintenance toolkit) was born - which now tells you all of the changed programs, and you can evaluate what is needed for testing and what isn't.

This is the product of a long standing (customer approved) policy that has the cobol applications always patched back to base zero release. So you apply a CTP, and all of the required deliverables for that patch are delivered. The AMT compares what is installed on your system against the deliverables in the CTP and only updates the ones that are newer. Based on that list, the impacted program list is built and then recompiles are done. And a nice little report is spit out to have your business teams review what programs were potentially impacted and what you should potentially go test.

So if you are sitting on version 10, MSP 5 (10.0.5), which was released 2 1/2-3 years ago, and you apply a CTP today, you are going to pull in a lot of updated deliverables, and your impacted program list will be much bigger than if you were sitting on 10.0.7 (released last year). A different customer, sitting on MSP 7 and having applied 700 patches on top would see far lesser impact from the same CTP.

There is no requirement on customers to stay current on application service packs (MSPs). That was discussed numerous times at the global user group level and the feedback from the user community was a resounding no. So if customers are going to be supported on many different MSP levels, this is the only way to manage that process. Or we go back to paper patches like we had in the 90s have customers manually apply the code changes

When you get off cobol and up onto the v11 products on Landmark - you will only get full complete builds of the product with each update. Everything is replaced, and you need to review the documentation to see where the product changes were made and structure your testing accordingly. At least now you have full visibility into every program that was potentially impacted. The good news is - with the push to enable these same v11 products in the multi-tenant cloud, quality becomes paramount. One critical regression deployed in the MT cloud impacts everyone. So there are major strives being made in QA and testing to support those efforts.

I understand why long-term Lawson clients feel they have to go through a huge testing cycle when a bunch of programs are potentially impacted by a patch. I was one before. Its because you have been burned by an introduced regression in the past. So I get it. But really - testing should be targeted around the specifics of the change. Infor doesn't expect our customers to be the QA department for our products. A level of trust is needed - with targeted testing - and staying somewhat current - all of that help reduce the effort.

One final note, I would highly recommend the "if it isn't broke, don't fix it" approach to CTPs. We release THOUSANDS each year. There is no need for a customer to take them all. The AMT will manage and update your code with the requirements you specifically need. I do recommend taking an MSP every 12-18 months, to bring you more up to date, but applying patches just to apply patches is a bit of a fool's errand - no offense intended.

unknown

Hi Karen, Here they are:

1. PR89 - The full patch was 113120 and it was huge. We appealed to Infor and they helped us perform the one change on PR89PD that was needed.

2. HR511 CTP - The full patch was 111058. That's probably been superceded and superseded and superseded. The HR511 issue was that the v10 increased address field size wasn't updated in HR511. We were bummed.

Lenny

unknown

Hello Hans, Good to see you contributing to the thread. Your comment is enlightening but not quite reality, based on our direct and recent experiences (and others, I'm hearing). Our approach, up until recently, was indeed the "If it isn't broke, don't fix it" one that you mentioned. And we weren't to far behind on MSP's. (actually just 1 up until recently!) What we found is that, *frequently* we, or our functional users, were opening tickets where, one of the first thing asked was, "What version of the PD are you on? ... Oh, you need to get to the current version" and then getting to the current version on the 1 PD required a patch of gargantuan proportion. Given the frequency of this, we modified our approach (just now, in fact) to "Let's proactively get up to current so that Support can't tell us to get to current when we're having an issue." And then, hopefully, we'll stop seeing so many defects. That's our hope anyway. We'll see how that goes. Thanks! Lenny

plancor

Hi Lenny, CTP 113120 is the patch that was recommended to us that prompted me to start this thread. I, also, appealed to Infor support, but they did not help me perform a less invasive change (as they seemed to have done for you). Do you mind sharing the name of the rep that was able to help you with this patch?

plancor

Thank you, Hans. I appreciate your insights. A couple comments and a question:

“This is nothing new” I agree – there have been mega patches in the past. However, it seems that they are more frequently the response received from support. I know I have in the past been able to apply patches that touch far fewer programs.

“I recommend taking an MSP every 12-18 months”. We went live on v10 June 27, 2016. As of December 27, 2016 (a period of six months), one change to one program necessitated a Functional Change to 868 programs. Performing a full testing cycle at least every six months puts quite a burden on our users.

“Testing should be targeted around the specifics of the change” So that I’m clear on this statement…are you saying that for the patch required to correct one change to PR140, we should only test PR140 – even though the patch Functionally Changes 865 programs? If that is true, AMEN!!!!

d-hofmann

For an MSP we do a full cycle testing.

For a single patch for something that is broken, we pull the compile list from the logs and publish that to the testers. If a form they use is recompiled, we expect them to test and sign off.

unknown

Hans, I have to agree with the others on this thread. We went live on 10.0.6 in May 2016. We do an MSP every spring so we stay relatively current. We have had a few patches lately where the CTP handed to us has hundreds of compiles. We get the same response as indicated by the others. What version of PD, get to newest PD, let me get you the CTP, CTP has hundreds of changes. We have not had this in all cases, but several.

lxiong3

As Jeff has mentioned we typically do MSP once a year and perform a full blown UAT.

Throughout the last year for Supply Chain we've run into issues and for the most part GSC has given us specific patches to resolve the issue, which could be due to us being more current. Testing these patches, I usually look at the preview and test all screens that have been updated and check the commonly used programs that will need to be recompile.

Copyright © 2025 Infor. All rights reserved.