Applying PRP’s – Reviewing What They Are and How They Work
***************************************************
Now that many customers are past the initial stages of
setting up and learning how to use PUM, they are beginning to aggressively
apply maintenance items for their 9.2 release. As part of this activity,
customers often need to apply PeopleSoft Release Patchsets (PRP’s) for fixes
that are not yet available within the latest PUM image release (as in the case
of the latest Tax Updates for HCM). The question of how PRP’s need to be
applied has come up several times in recent months, either through
customer-logged SR’s or internal requests for assistance. Therefore, a review
of how this process works is warranted.
PRP’s are defined as being patches that must be delivered
in-between PUM image release cycles. PRP’s are searchable and downloadable
individually from MOS, but the key thing to keep in mind about PRP’s is that
they *must* (and can only) be applied to the latest PUM image (not directly to
a Target environment). The two key implications of this statement are:
PRP’s cannot and
should not be applied directly to a Target database environment. Instead, PRP’s
need to be applied to the latest PUM Source environment, PUM is then used to
create a Change Package containing the desired patch(es) and the Change Package
then applied against the Target database environment. The reason for this is to
make sure that all pre and post requisites (determined by PUM) are included in
the Change Package that is applied to the Target.
PRP’s become ‘obsolete’ and can no longer be downloaded once
a newer PUM image is posted. The reason for this is because the newer PUM image
already includes any PRP’s released between the time period of the previous PUM
image and the current PUM image, thus eliminating a need for the PRP.
Additionally, PRP’s that may have been downloaded previously (even if never
applied to a PUM environment at that time) will not be able to be applied to
the newer, ‘current’ PUM environment for the same reason. PRP’s are created and
effectively only intended to be used for a single, specific PUM image release.
As an example, a PRP created while HCM PUM #5 is considered to be the ‘current’
PUM image, will only be available for download until HCM PUM #6 becomes
available, and can only ever be applied to an HCM PUM #5 environment. Such a
PRP, even if downloaded previously and never applied at the time, cannot be
applied to an HCM PUM #6 environment. In this regard, PRP’s also function
differently than the ‘individual postings’ that exist for non-PUM releases.
Please keep in mind that PRP’s are also distinct from POC
requests. PRP’s represent patches that are either of a Severity-1 nature or
patch requests that have been escalated to Development, and for which
Development has properly ‘packaged’ and will deliver the formal code changes
within the next scheduled PUM image release cycle. The PRP patches are then
individually posted to MOS and made available for customers to download and
apply. PRP’s are also made generally available and intended for usage by any
customers who may need them. In contrast, POC requests are for ‘Proof of
Concept’ patches that have not been formally ‘packaged’ yet by Development and
are very much still in an ‘unconfirmed’ state. POC requests are also typically
‘password protected’ and intended for usage by a single customer only. A POC
may at some point ‘become’ a PRP, but during the period that a particular set
of code changes is still being tested/verified by a customer (as is often the
case for performance-type issues, etc.) these types of changes will continue to
be delivered as POC requests and only on an ‘as needed basis’ with approval
from the respective Development team working on an issue.
No comments :
Post a Comment