[SOLVED] Identifying Quick-Patches Installed

[chrisplough]

In order to identify which Quick-Patches are installed on an OTM system, you just need to cat <otm_install_dir>/glog/config/glog.patches.properties. The contents of the file will look like the following, with each line identifying an installed QP:

installed_patch=otm55_quickpatch_5770356 (5770356)
installed_patch=otm55_quickpatch_5767727 (5767727)

Note: This may only apply to newer OTM systems and QPs installed in the last 1-2 years, since the QP installer was revamped somewhere along the line, though the G-Log years meld together now, so I don't remember exactly when it took effect

Thanks to Paul F. for including this functionality in the Quick-Patch installer -- it definitely makes my life easier!

Hope this helps!

--Chris

[saufil chang]

Re: Identifying Quick-Patches Installed

Hi,
I'm new in the OTM G3, hopefully you can help me? Kindly i like to know instruction how to install pathes.

Thanks.

[chrisplough]

Re: Identifying Quick-Patches Installed

Hello!

There are 3 types of patches for OTM:

• Cumulative Updates (CUs) - Big service releases for OTM. Testing is very thorough.
• Roll-up Patches (RPs) - Small update packages consisting of many small Quick Patches. Testing is pretty thorough.
• Quick Patches (QPs) - These are one-off patches created in reaction to high-priority Service Requests (SRs). Testing is minimal.

Please reference the README file included with each patch set, as they contain full installation instructions and often include custom steps for that particular patch.

However, here are some helpful notes:

• The installation for each is different, though the most common patches that clients install are the CUs.
• For all OTM patches, it is important that they are applied to all tiers (web, app, rpt and db).
• Once you've installed the OTM patches on the OTM App tier, you'll have the files necessary to run the DB portion of the patch, which includes logging into the OTM DB and running a script like dbpatch_55.sql.
• OTM DB patches are atomically transactional, so if they fail at some point, you can resolve the issue and re-run. They will continue from the point of failure.
• OTM patches (except QPs) are generally not reversible. It is important to make backups of both your application files and DB prior to applying patches.
• OTM patches require downtime - all OTM tiers (web, app, rpt) must be shutdown for the application of the patches.
• ALWAYS apply OTM patches to a TEST/DEV environment first and run through full regression testing prior to promoting to PROD.

Let me know if you have any specific questions and I'll answer them.

Hope this helps!

--Chris