Software Update plugin enhancements - Add the ability to automatically identify and retrieve any missing PTF's and download/receive them and rerun the APPLY CHECK. Also identify PE PTF's that cannot be APPLYed and exclude them.

The requested features already exist in z/OSMF Software Management, therefore this IDEA will be closed.

Josh, thank you for the response. Glad to hear you run an automated RECEIVE every day. If you receive the latest PTFs every day, then you should never have the situation where a PE-fixing PTF is available but not yet received. You certainly may try to install a PE PTF where a fixing PTF is not yet available, but since a fix is not yet available then the only option is to either exclude the PE PTF, or bypass the PE ERROR HOLD. The Install Recommended Updates action in Software Update automatically excludes PE PTFs, whereas the Install Corrective Updates action allows you to choose either to exclude a PE PTF, or bypass the PE ERROR HOLD.

I hope this information helps and explains how I believe Software Update already provides the functions you requested. However, if you still have specific thoughts and suggestions on how to improve Software Update, please let me know.

Regarding your frustrations and troubles using Software Update recently, I am happy to discuss this topic separate from this IDEA to determine the specific issues. Feel free to contact me via email if you want to followup, at kurtq@us.ibm.com.

Thank you for submitting this IDEA to improve z/OSMF Software Update. Upon reading the IDEA I believe there are three separate suggestions. Before I respond to the overall IDEA, please help clarify your specific suggestions.

1. Identify and retrieve any missing PTF's and download/receive them and rerun the APPLY CHECK.
2. Identify PE PTF's that cannot be APPLYed and exclude them.
3. Customize the jobcard (to include parms like a time parm and region parm).

For suggestion 1, IBM's recommended best practice is to automate running SMP/E RECEIVE ORDER on a regular and frequent cadence, thus avoiding situations where PTFs are missing and not yet received. In any case, can you please be more specific what you mean by "missing PTFs"? Do you mean a not-received PTF that is identified as a requisite (PRE, REQ, or IFREQ) for a received and selected PTF? Do you mean a not-received PTF that resolves a PE for a received and selected PTF? Do you mean a PTF that you identify by name that is not yet received? Other?

For suggestion 2, the Install Recommended Updates action selects PTFs to install based on their associated source IDs. Currently this action already identifies selected PTFs that have unresolved PEs and does exclude those PTFs from the install. Is this processing different than your suggestion? If not different, how is the current processing not sufficient?

For suggestion 3, in z/OSMF Software Update the SMP/E install operations do not run in a submitted job via generated JCL, therefore, there is no JCL JOB statement to customize. Instead SMP/E runs in a TSO address space. For the TSO address space z/OSMF currently allows you to specify the following values used when starting TSO: the TSO login procedure, region size, and account number. You may specify these values on the COMMON_TSO statement in the z/OSMF server's IZUPRMxx PARMLIB member. Do these options provide sufficient customization? If not, what specific additional customization do you believe is required for the started TSO address space?

Thank you again for your IDEA. I look forward to your response.
Kurt Quackenbush
IBM, z/OSMF Software Management