Re: change management for ptf's

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