On 23 May 2012 05:25, rob@xxxxxxxxx wrote:
I was recently taken to task on this list for not using proper
change management for PTF's, with the person believing it would
help me with my quest to find test ptf's and
ensure that I do not permanently apply them.
What would the change management for that be? <<SNIP>>
System Change Management is much about processes and the procedures
that implement them. Procedures to ensure that whatever changes are
implemented have been tracked [and the justification, plus the timing of
changes may be reviewed for correlation to problems arisen since], that
the changes can be backed-out if they [appear to] cause problems, and
that desirable changes are re-applied when other processes [e.g.
upgrade\install] would effect their removal.
One such process is PTF management on a system. The testPTFs are
already dealt with, in part, using an exception process; i.e. they are
obtained via negotiated release for download. Thus I would introduce
something similar within the overall process for dealing with PTFs for
the system, an exception process that would enable tracking those test
PTFs explicitly and separately from the PTFs normally being tracked
mostly [or only] by the OS PZ feature; i.e. tracked outside of what is
provided by the commands at GO PTF.
After negotiating with IBM to get the testPTF, the PTF is downloaded;
presumably into either a save file [as part of *SERVICE].? At that
point I would use some internal alternate\exception process to start
tracking that PTF ID for any future dealings with the LODPTF and APYPTF
processing; possibly even for RMVPTF. That procedure in the exception
process would effect recording the PTF identifier(s) for the test PTF,
for reference by those future PTF process activities.
The procedures to effect permanent apply processing would be modified
also, to first check the recorded [list of] test PTFs; effectively
desired the addition of those as "PTF numbers to omit" (OMIT) parameter
of that request to APYPTF. Effecting a similar change in procedure, to
prevent a LODPTF from applying a superseded testPTF could be worthwhile
as well; i.e. just as troublesome for effecting a permanent-apply, but
probably much less likely.?
Tracking on paper would probably suffice for most, but searching back
through a list of a vast array of written change entries is often
cumbersome and error-prone. If there are only very few and rare
exceptions, and a list is maintained specific to this type of exception,
then that is probably not a problem; e.g. some bound pages each having a
PTF ID recorded, and when the PTF is no longer designated as "test",
then that page is erased or removed. Dependence on review of some
written list rather than enforcement within the normal processing is
also error-prone; i.e. unless the process that effects LODPTF and APYPTF
somehow automates either the review or the actual prevention of the
perm-apply, then there is more likely to be a failure in the process.
Instead of paper tracking, creating CL command(s) to implement the
tracking could be an approach to record the results somewhere; e.g. in a
database [source] file. Perhaps a command like "Track Test PTF"
TRKTSTPTF ACTION(*ADD|*RMV|*RPT[|*CMP|*VLD|*DSP|*CHK]) LICPGM() PTFID(),
that would implement the tracking. Having the data stored similar to
DSPPTF output to an OUTFILE() [or just enabled to be represented as a
TABLE similarly; e.g. via UDTF or VIEW], as a row for each PTF ID, then
a join could be performed to validate consistency of tracking between
the internal processing and the OS PZ processing [although for lack of a
"test" designation, limited to things like "if already perm-applied,
then no reason to continue tracking this as a testPTF"] or even just
reporting data like status and date\time of each tracked PTF while
avoiding storage of that information in two places. Stored as a long
string of blank separated values, that allows easiest generation of an
interpreted OMIT(string) for both LODPTF and APYPTF. After the PTF is
confirmed to have been made GA [without having been re-created; i.e. the
current copy is the GA copy], then the entry tracking that PTF ID would
be removed from the list.
Regards, Chuck
midrange.com
