Reminds me of the time that someone asked what changes are going in with a maintenance cycle. Supplied them with a LISTMCS of all the PTFs that were applied. Never heard back from them again.
Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&[email protected] On Tuesday, December 10th, 2024 at 8:17 PM, Steve Beaver <[email protected]> wrote: > I’m going to say this because we all learned via RTFM. I would suggest that > you dump the SMPe output to paper. Point the auditors at the PDF’s and tell > them come back in a week with questions. > > > Sent from my iPhone > > No one said I could type with one thumb > > > On Dec 10, 2024, at 18:16, Joel Ewing > > [email protected] wrote: > > > > I'm betting the auditor's level of understanding is pretty low here -- > > probably just a concept that putting code with a known error into > > production is always bad. The reality of course is that if you have been > > doing z/OS maintenance long enough, you know every system placed into > > production has unknown errors, some of which could end up being serious. > > Over time, as more errors are discovered and communicated to IBM resulting > > in APARS and HOLDs, you end up with a production system with both known and > > unknown errors. IBM issues PTFs to fix known errors, and if those PTFs are > > later found to have errors, a later ERROR hold is put on the PTF. The only > > difference between APPLY and APPLY BYPASS for that PTF is a matter of > > timing: when you do the APPLY versus when the ERROR hold on the PTF is > > issued. The odds are that every time you do major maintenance, you will > > invariably have applied some PTFs that at a later time will be found to > > contain errors. > > > > Normally you wouldn't want to place a PTF that has an ERROR hold into a > > production system, but on rare occasions you encounter a HELD PTF that > > fixes a problem that is very serious for your installation, while the ERROR > > hold is a minor issue or even no problem for your installation because of > > your configuration. If no resolving PTF is available, in such a case it may > > be desirable to BYPASS the ERROR hold to replace a critical problem with a > > minor one. This is a judgement call based on detailed knowledge of your > > specific system environment, and frankly not something a generic auditor is > > qualified to judge or question. When applying quarterly maintenance, you > > can try to maximize the number of PTFs installed and still avoid needing > > BYPASS by obtaining any later Error-hold-resolving PTFs that are available, > > but these newer resolving PTFs have had less usage and could themselves > > contain errors that just haven't been found yet. > > > > To me, the fixation of the Auditors on APPLY BYPASS indicates lack of > > understanding. It would make more sense to look for evidence about how > > often HOLD data was received and a REPORT ERRSYSMODS performed to check > > whether there are any known problems in production that are urgent enough > > to resolve before the next maintenance cycle. With z/OS, no reasonable > > SysProg puts major maintenance directly into a production system, but > > builds a "new" system whcih only becomes production after sufficient > > testing and resolution of problems. It is irrelevant whether building that > > new system included any APPLY BYPASS operations, only whether there are > > significant ERRSYSMODS remaining after the testing and problem resolution. > > If the timing of other events (like new hardware) forces putting a system > > with known unresolved ERRSYSMODS into production, one would hope there is > > enough review of the nature of those known errors to give some assurance > > the risk is minimal. > > > > JC Ewing > > > > > On 12/10/24 11:20 AM, Phil Smith III wrote: > > > Can we first stop and be impressed that an auditor understands enough to > > > ask about this? > > > > > > -----Original Message----- > > > From: IBM Mainframe Discussion List [email protected] On Behalf Of > > > ITschak Mugzach > > > Sent: Tuesday, December 10, 2024 12:16 PM > > > To: [email protected] > > > Subject: Re: SMPE and auditors > > > > > > Let your auditor access to the smp log files and find the answer himself. > > > > > > ITschak > > > > > > *| *Itschak Mugzach | Director | SecuriTeam Software | IronSphere > > > Platform | *Information Security Continuous Monitoring for Z/OS, zLinux > > > and IBM I **| * > > > > > > | Email*: [email protected] | Mob: +972 522 986404 | > > > Skype: ItschakMugzach | Web: www.Securiteam.co.il *| > > > > > > בתאריך יום ג׳, 10 בדצמ׳ 2024 ב-19:12 מאת Jousma, David < > > > [email protected]>: > > > > > > > All, > > > > > > > > I have an auditor that would like to see if there were any PTF’s applied > > > > in my environment where BYPASS HOLDERROR was specified. Its not enough > > > > for me to tell them that there weren’t any. I have been playing around > > > > with SMPE list commands, and can list PTF’s where BYPASS was specified, > > > > but > > > > no further granularity that I can see. And I guess it’s a bit more > > > > complicated than that, as rare as it is to bypass HOLDERROR, I could > > > > forsee one being applied after talking with support center, and then > > > > later, the fixing PTF came along and was applied. > > > > > > > > Any ideas that I am missing? > > > > > > > > Dave Jousma > > > > Vice President | Director, Technology Engineering > > > > > > > > This e-mail transmission contains information that is confidential and > > > > may > > > > be privileged. It is intended only for the addressee(s) named above. If > > > > you receive this e-mail in error, please do not read, copy or > > > > disseminate it in any manner. If you are not the intended recipient, > > > > any disclosure, copying, distribution or use of the contents of this > > > > information is prohibited. Please reply to the message immediately by > > > > informing the sender that the message was misdirected. After replying, > > > > please erase it from your computer system. Your assistance in > > > > correcting this error is appreciated. > > > > Joel C Ewing > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
