Cumulative Patches - Best Practice

 Most if not all of the organizations I've been involved with apply them only as "needed". Here are some points you also may want to take note of:

1) Test any and all patches before they are applied to Production. Get approval and sign off on the patches (if needed) before moving them to production. I think this applies to most organizations but no one has the manpower to keep up with the daily/weekly patches. Many patches you may not need or use.

2) Any critical environment patches, you need to be aware of. Sign up for emailing of the notice of those critical patches from mylawson.com. All critical notices are also within mylawson.com.

3) Also become involved with your Lawson user groups so you can connect with other organizations which use Lawson.

Roger

This is a topic we have been working on a process around for a while now. We continue to tweek our process but have found that more and more patches are being bundled together and any ESP or environment patches are almost to the point of needing a round of testing.

Here are the things that are concerns we are addressing:
* If a PT is discovered to be needed, we run it in preview mode to see what programs actually change. This is more work on the IT staff but looking at what programs are compiled vs which ones actually change the program.
*If you are not in the window of support (2 ESP/MSP's back from current). Support will usually point you to one of these to "get current" then will address patches. The proactive planning should keep you in the window rather than having to on the fly request testing resources from the departments to fix issues.
*We have schedule downtime windows each month that we try to hit any of the ESP/MSP and have a plan now that is communicated to the users as to the window we are targeting for these cumulative patches.
*Any ESP we are requiring a full round of testing. We have found many of these will have a new lawsec.jar file that can play havoc with rules and access and so we are asking for validation that nothing is impacted by these changes.

Hope that helps

I strongly recommend applying patches only as "needed". The bundled patches are breaking things left and right. I wish lawson would put more people in QA before releasing patches. For example, I applied a patch to address an issue with laser print output recently and it broke AC activity validation. I am still working with lawson on this with an open case...

I resisted to put this particular "bundled" patch in because it's just a small laser print issue. I argued to no end and I was assured by 2 lawson support that this patch will not cause problem. I waited month(s) until I could not delay any further to fix the laser print issue. Then guess what? The patch caused problem. On top of that, each payroll run now, with the bundle patch, it creates additional laser print PMTOUTI files for the iseries. We are not even on the iseries platform. Fun!

Thank you for your feedback, it is great to get others views and experiences to bring a full view of things.

Thanks
Dave

Lawson released a critical ntification somewhere in the middle of Feb that says they will support the latest release or one lower than the latest release. This means that if you call support for any issues you are having with any release of applications or environment or any of their products they will support you but if the fix involves writing a patch they will write a patch only if you are on the latest release of Lawson for that env/app/built on or one lower than the latest release.

When lawson announced this we now have to plan upgrading every year to the latest env/app/built on atleast once a year to stay current. You may want to chech with your account rep of Lawson to see how this affects your maintenance cycles and plan ahead of time.

I'm trying to wrap my head around what testing would be needed for ESP's vs MSP's. MSP would be full system testing, but would an ESP need that also or would we just need to run one each of 1) an online program 2) an interface, etc.???

From the post here that I'm replying to, I saw one person state ESP would mean FULL system testing. I was hoping that for what role the environment plays, it would not require full system testing from all functional areas..but I'm clueless really.

What are others doing for this? We just learned that we may need the post patches to ESP 5 and I know that the functional folks will NOT like a request for FULL system testing thrown at this during this time of year.

Beverly,

The reason I stated that a ESP may require a full test is that many time you will get a new lawsec.jar file. We installed environment patches in since going to LSF 9.0 that we thought would have no impact to the users. What we found was the new secruity (lawsec.jar) file impacted programs, access and rules in LS security. Based on that and getting skewered by our user community, we have made the decision to request a full test cycle with environment patches/ESP's.

You may be fine the majority of the time. This caused our users to lose confidence in the testing process and required us to change our thought process on these types of patches. I hope that helps you understand our position. If you have other questions feel free to contact me at any time.

We are not on the new lawson security..we are still doing the laua, so I'm not sure that we have the same scenario. Of course full system testing would always be the safe bet...but based on what role the environmnt plays with the application, would it be necessary to test every application if it is just an Enviro patch? What are others doing on this?