Re: OpenSSH upgrade option
Paul Jodlowski wrote: >Currently OpenSSH is at 6.4p1, I have been asked by our >Network Security Team to upgrade to OpenSSH 7.4. That's an "amusing" recommendation from your Network Security Team. Unless security patches have been backported and applied to a particular distribution of OpenSSH, OpenSSH 7.4p1 has at least three known security vulnerabilities that I see: CVE-2018-15919, CVE-2018-15473, and CVE-2017-15906. So is your Network Security Team running around and getting lots of other systems "updated" to an insecure release of OpenSSH (7.4), if those other systems don't have backported security patches? Probably. Ooops. I think you'll need to educate your colleagues (politely, diplomatically) on how security patching and backporting works. It's great they're checking -- too few organizations do even that -- but they're not checking well, and their advice is not helpful. As a general or at least widespread practice, and for decades now, software version and release numbers often refer to *functional* levels. In Db2 for z/OS, for example, this concept is now explicitly labeled "Function Level" just to remove ambiguity, e.g. "Function Level 502." In contrast, security updates and patches typically flow through the service stream, using PTF/APAR numbers (as in z/OS), fixpack or service pack indicators (e.g. "SP8"), date codes (e.g. "20190204"), or some other indicator that isn't part of the major version and release level. That's what your security teams should regularly check for, and that's how they should express their recommendations if they spot something missing. z/OS OpenSSH is a fully IBM supported component of z/OS. As long as you're on a supported release of z/OS, then backported patches for security and defects -- and sometimes functional improvements -- are available to you as part of the service stream and should be promptly applied per your preventive maintenance plan. (You should have such a plan.) As others have mentioned, you should subscribe to the IBM Z Security Portal, and you should also closely monitor at least the fixes marked HIPER. Just to drive home this point, this practice isn't peculiar to mainframes or even to servers. For instance, if you have a desktop or laptop PC running Microsoft Windows, you can be running any of several functional versions/levels of Windows that are all still Microsoft supported, with security patches available for all those supported function levels. Just looking at Windows 10, here are the versions that are still receiving security updates from Microsoft (as I write this, and without any special support contracts): Windows 10, version 1703 (Enterprise and Education editions only) Windows 10, version 1709 (Enterprise and Education editions only) Windows 10, version 1803 Windows 10, version 1809 Yes, that's four versions of the Windows 10 product alone, in multiple editions, that Microsoft is supplying with security patches through their regular (non-extended) service streams. But if you have some security team say, "You should install Windows 10, version 1803," that's bad advice as such. Version 1803 as it originally shipped has several known security defects. No, they need to check for specific security patches and, when they find something missing, provide actionable advice on which specific patches to apply. For Microsoft's products, patch identifiers start with the letters "KB" followed by a sequence of digits. So the correct advice would be something like this: "According to our latest check, System XYZ123 is missing Microsoft security patches KB012345, KB012346, and KB987653. Our preventive maintenance plan for Windows desktops and laptops requires applying all security patches within 45 days unless the operations team has granted a temporary waiver for good cause, and subject to special conditions and limitations. Please apply these missing security patches, and any others, right away. We will check again within the next few days to verify that the patches have been successfully applied." Bonus points are awarded if your security teams also check for End of Service dates (to keep on eye on whether you and others are getting too close to the end of security patch availability), review preventive maintenance plans, and make sure those plans are being followed well. Example: "Also, after you apply these patches, we recommend that you upgrade from Windows 10, version 1709, to the latest version of Windows within the next 90 days. Version 1709 will reach End of Support soon and will no longer be able to comply with our preventive maintenance plan." Unfortunately you might have to tell your security team how to do their jobs competently. Be gentle. :-) Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE E-Mail: sipp...@sg.ibm.com -- For IB
Re: OpenSSH upgrade option
Paul Jodlowski wrote: >>Currently OpenSSH is at 6.4p1, I have been asked by our Network Security Team >>to upgrade to OpenSSH 7.4. z/OS OpenSSH at 6.4p1 is a fully supported by IBM. Your Network Security Team is asking you to 'upgrade', but actually they want to have you to upgrade to an unsupported open version of OpenSSH [on z/OS]. As Timothy Sipples said, IBM will, if needed, backport the OpenSSH. Timothy is right about Db2, it is also same with REXX. You get the official supported REXX at whatever z/OS level from IBM, but there are many commercial and free versions of REXX on other platforms. So, in other words, the Network Security Team wants to have you to throw away official supported OpenSSH? No ways! I would simply refer them to IBM after a lot of explanation of course. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Fwd: Incoming | Computerworld SHARK TANK
https://www.computerworld.com/article/3388298/incoming.html Regards, Mark T. Regan, K8MTR CTO1 USNR-Retired, 1969-1991 Nationwide Insurance, Retired, 1986-2017 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OpenSSH upgrade option
Paul Gilmartin wote: " Would IBM do better to apply IBM patches to the newest distribution rather than trying to upgrade an outdated version with APARs? There's yet no assurance that IBM's patching won't regress a needed security patch Is EBCDIC a culprit?" This has nothing to do w/EBCDIC. This is a new standard from the IETF (or whomever). Like any other software, OpenSSH was written to a certain spec. A new spec will require new code to support that spec. Since OpenSSH is now a part of z/OS, obviously maintenance will be required. As I said in my earlier post, IBM is (more or less) obligated to support the new standard. Whether this is done with a (PTF) or (FUNCTION SYSMOD) is irrelevant. Patch (apply PTF) vs. Replace (apply new function) is (IMO) *NEVER* a vendor decision. Which update method produces the desired result with the least amount of effort? It would not surprise me (I haven’t investigated) if IBM has supplied both methods. To the OP: It seems a PMR or call to your friendly IBM rep would provide the information needed. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Thursday, April 11, 2019 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OpenSSH upgrade option On Thu, 11 Apr 2019 16:01:15 +, Mark Jacobs wrote: >I don't believe so. Latest version shipped with z/OS 2.3 is 6.4p1. IBM does >issue APARs against it for any problems found that are applicable to OpenSSH >on zOS. These is/was a list of them in one of the IBM OpenSSH manuals at one >time. > It's reasonable that Security Team look first at the version number and reject immediately if it doesn't meet criteria. They haven't resource to examine every APAR cover letter (and integrity APARs may not be public.) Would IBM do better to apply IBM patches to the newest distribution rather than trying to upgrade an outdated version with APARs? There's yet no assurance that IBM's patching won't regress a needed security patch. Why must IBM patch? Is EBCDIC a culprit? I hate EBCDIC! >‐‐‐ Original Message ‐‐‐ >On Thursday, April 11, 2019 11:44 AM, Paul Jodlowski wrote: > >> Is there a way to upgrade OpenSSH on z/OS v2.2? >> Currently OpenSSH is at 6.4p1, I have been asked by our Network Security >> Team to upgrade to OpenSSH 7.4. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Incoming | Computerworld SHARK TANK
That reminds me another story. ten years ago a client of us installed a new hitachi disk array. The technician installed and configured the array, but for some reasons, it was not immediately used by the client. few days later, the client tried to connect to the array and it was down. it was repeatedly don everyday afterwards. investigation showed that the the people who cleans the computer room unplugged the power for the vacuum cleaner... The array was using a standard power plug. ITschak On Fri, Apr 12, 2019 at 3:36 PM Mark Regan wrote: > https://www.computerworld.com/article/3388298/incoming.html > > Regards, > > Mark T. Regan, K8MTR > CTO1 USNR-Retired, 1969-1991 > Nationwide Insurance, Retired, 1986-2017 > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lousy error from HLASM in USS
I think the grumpiness and sarcasm might be a bit over the top. The error does have roots going back to the middle ages, that when combined with modern functionality, causes some odd results. Anyway it's something that doesn't happen very often. If IBM thinks it's worthwhile, they'll improve it. I doubt there's any reason to worry about error message compatibility. sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Incoming | Computerworld SHARK TANK
ITschak Mugzach wrote: >... investigation showed that the the people who cleans the computer room >unplugged the power for the vacuum cleaner... The array was using a standard >power plug. Hahaha! I heard a similar, but false story. ( https://www.snopes.com/fact-check/polished-off/ ) Apparently in a hospital in our country, some patients died during a specific shift. Same story, cleaners/janitors unplugged life supporting equipment to do their cleaning with vacuum cleaners and polishers and thus 'polished off the patients'. Also there is a false rumour that in a San Francisco hospital, during Earth Hour the patients were killed during that hour... https://www.snopes.com/fact-check/hour-dearly-beloved/ ;-) Groete / Greetings Elardus Engelbrecht PS: Many years ago, after a mechanic swapped the oxygen and vacuum pipes and a patient died there-after, now these days all plugs and pipes (electrical, vacuum, oxygen, etc. ) are marked with different colors and shapes. Life supporting equipments plugs on the walls are marked with a warning that they are NOT to be unplugged. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fwd: Incoming | Computerworld SHARK TANK
On Fri, 12 Apr 2019 08:35:39 -0400, Mark Regan wrote: >https://www.computerworld.com/article/3388298/incoming.html > Somehow similar, a GPS rollover glitch took down (some) NYC wireless communications last week: https://www.nytimes.com/2019/04/10/nyregion/nyc-gps-wireless.html ... happens every 19.6 years; previously August, 1999. You'd think they'd learn. Others cited at: http://mm.icann.org/pipermail/tz/2019-April/027859.html And even: The Earth's not slowing down fast enough to suit Motorola http://catless.ncl.ac.uk/Risks/22/94#subj3 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Dumps and cancelling jobs
The discussion about non-recoverable abends and cancelling jobs brings to mind an "issue" I've had since we migrated from z/VSE to z/OS in 2010. If I recall correctly, if a job was cancelled in z/VSE the "dump analysis" product (Abend-Aid, IBM Fault Analyzer, et al) would still get control and produce a nice formatted dump. With z/OS this does not appear to be the case. So if we cancel a job that, for example, appears to be in a infinite loop we have no way to know even where within the program its looping, much less what the program data is. Did we perhaps just miss some option that would allow our dump analysis program to take control when a job is cancelled? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumps and cancelling jobs
You probably will get what you want with C jobname,DUMP console command, or CD in a SDSF screen. Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, April 12, 2019 12:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dumps and cancelling jobs The discussion about non-recoverable abends and cancelling jobs brings to mind an "issue" I've had since we migrated from z/VSE to z/OS in 2010. If I recall correctly, if a job was cancelled in z/VSE the "dump analysis" product (Abend-Aid, IBM Fault Analyzer, et al) would still get control and produce a nice formatted dump. With z/OS this does not appear to be the case. So if we cancel a job that, for example, appears to be in a infinite loop we have no way to know even where within the program its looping, much less what the program data is. Did we perhaps just miss some option that would allow our dump analysis program to take control when a job is cancelled? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OpenSSH upgrade option
On Fri, 12 Apr 2019 15:35:55 +0800, Timothy Sipples wrote: >Paul Jodlowski wrote: >>Currently OpenSSH is at 6.4p1, I have been asked by our >>Network Security Team to upgrade to OpenSSH 7.4. > >That's an "amusing" recommendation from your Network Security Team. Unless >security patches have been backported and applied to a particular >distribution of OpenSSH, OpenSSH 7.4p1 has at least three known security >vulnerabilities that I see: CVE-2018-15919, CVE-2018-15473, and >CVE-2017-15906. > I find these mentioned at site:ibm.com, mostly referring to AIX and IBM i. Can the OP find relevant APARs/PTFs to show Security Team? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OpenSSH upgrade option
WTF? A z/OS PTF *can* include a patch, but it is normally a total replacement. And it most certainly is a vendor decision how to install upgrades. That said, IBM normally provides ++ APAR as a temporary expedient, and then provides a PTF with the appropriate SUP keyword. An RSU will have the PTF. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Allan Staller Sent: Friday, April 12, 2019 9:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OpenSSH upgrade option Paul Gilmartin wote: " Would IBM do better to apply IBM patches to the newest distribution rather than trying to upgrade an outdated version with APARs? There's yet no assurance that IBM's patching won't regress a needed security patch Is EBCDIC a culprit?" This has nothing to do w/EBCDIC. This is a new standard from the IETF (or whomever). Like any other software, OpenSSH was written to a certain spec. A new spec will require new code to support that spec. Since OpenSSH is now a part of z/OS, obviously maintenance will be required. As I said in my earlier post, IBM is (more or less) obligated to support the new standard. Whether this is done with a (PTF) or (FUNCTION SYSMOD) is irrelevant. Patch (apply PTF) vs. Replace (apply new function) is (IMO) *NEVER* a vendor decision. Which update method produces the desired result with the least amount of effort? It would not surprise me (I haven’t investigated) if IBM has supplied both methods. To the OP: It seems a PMR or call to your friendly IBM rep would provide the information needed. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Thursday, April 11, 2019 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OpenSSH upgrade option On Thu, 11 Apr 2019 16:01:15 +, Mark Jacobs wrote: >I don't believe so. Latest version shipped with z/OS 2.3 is 6.4p1. IBM does >issue APARs against it for any problems found that are applicable to OpenSSH >on zOS. These is/was a list of them in one of the IBM OpenSSH manuals at one >time. > It's reasonable that Security Team look first at the version number and reject immediately if it doesn't meet criteria. They haven't resource to examine every APAR cover letter (and integrity APARs may not be public.) Would IBM do better to apply IBM patches to the newest distribution rather than trying to upgrade an outdated version with APARs? There's yet no assurance that IBM's patching won't regress a needed security patch. Why must IBM patch? Is EBCDIC a culprit? I hate EBCDIC! >‐‐‐ Original Message ‐‐‐ >On Thursday, April 11, 2019 11:44 AM, Paul Jodlowski wrote: > >> Is there a way to upgrade OpenSSH on z/OS v2.2? >> Currently OpenSSH is at 6.4p1, I have been asked by our Network Security >> Team to upgrade to OpenSSH 7.4. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --
Re: OpenSSH upgrade option
Gil: I have not found any APARs/PTFs for z/OS. I will probably just stop the OpenSSH services (as I started for a proof of concept with CyberArk) Thanks all for your suggestions -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, April 12, 2019 11:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OpenSSH upgrade option On Fri, 12 Apr 2019 15:35:55 +0800, Timothy Sipples wrote: >Paul Jodlowski wrote: >>Currently OpenSSH is at 6.4p1, I have been asked by our Network >>Security Team to upgrade to OpenSSH 7.4. > >That's an "amusing" recommendation from your Network Security Team. >Unless security patches have been backported and applied to a >particular distribution of OpenSSH, OpenSSH 7.4p1 has at least three >known security vulnerabilities that I see: CVE-2018-15919, >CVE-2018-15473, and CVE-2017-15906. > I find these mentioned at site:ibm.com, mostly referring to AIX and IBM i. Can the OP find relevant APARs/PTFs to show Security Team? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumps and cancelling jobs
Abend-AID has some global configuration options, right? I don't know the product, but I recall seeing "no dump due to installation options" or something like that. (Not to disagree with @Chris who is of course correct.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Christopher Y. Blaicher Sent: Friday, April 12, 2019 9:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dumps and cancelling jobs You probably will get what you want with C jobname,DUMP console command, or CD in a SDSF screen. Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, April 12, 2019 12:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dumps and cancelling jobs The discussion about non-recoverable abends and cancelling jobs brings to mind an "issue" I've had since we migrated from z/VSE to z/OS in 2010. If I recall correctly, if a job was cancelled in z/VSE the "dump analysis" product (Abend-Aid, IBM Fault Analyzer, et al) would still get control and produce a nice formatted dump. With z/OS this does not appear to be the case. So if we cancel a job that, for example, appears to be in a infinite loop we have no way to know even where within the program its looping, much less what the program data is. Did we perhaps just miss some option that would allow our dump analysis program to take control when a job is cancelled? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OpenSSH upgrade option
Who says IBM patches? How could EBCDIC conceivably be relevant? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Thursday, April 11, 2019 4:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OpenSSH upgrade option On Thu, 11 Apr 2019 16:01:15 +, Mark Jacobs wrote: >I don't believe so. Latest version shipped with z/OS 2.3 is 6.4p1. IBM does >issue APARs against it for any problems found that are applicable to OpenSSH >on zOS. These is/was a list of them in one of the IBM OpenSSH manuals at one >time. > It's reasonable that Security Team look first at the version number and reject immediately if it doesn't meet criteria. They haven't resource to examine every APAR cover letter (and integrity APARs may not be public.) Would IBM do better to apply IBM patches to the newest distribution rather than trying to upgrade an outdated version with APARs? There's yet no assurance that IBM's patching won't regress a needed security patch. Why must IBM patch? Is EBCDIC a culprit? I hate EBCDIC! >‐‐‐ Original Message ‐‐‐ >On Thursday, April 11, 2019 11:44 AM, Paul Jodlowski wrote: > >> Is there a way to upgrade OpenSSH on z/OS v2.2? >> Currently OpenSSH is at 6.4p1, I have been asked by our Network Security >> Team to upgrade to OpenSSH 7.4. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lousy error from HLASM in USS
On Fri, 12 Apr 2019 09:23:40 -0400, Steve Smith wrote: >I think the grumpiness and sarcasm might be a bit over the top. The error >does have roots going back to the middle ages, > IBM should operate a booth at Renaissance Faire. Or Comic Con. > ... that when combined with >modern functionality, causes some odd results. Anyway it's something that >doesn't happen very often. If IBM thinks it's worthwhile, they'll improve it. > That would be an RFE. As new facilities such as zFS appear it happens increasingly often. > ... I doubt there's any reason to worry about error message compatibility. > I'm staying with my assumption that the message is formatted by SYNADAF. SYNADAF is admirable; it's reusable code. Not every facility needs to write its own diagnostic formatter. But wide use engenders wide exposure to incompatibility. How many callers make assumptions about SYNADAF message format? Probably nonzero. In: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad500/syndf.htm The SYNADAF macro uses register 1 to return the address of an area containing a message. The message describes the error, and can be printed by a later PUT, WRITE, or WTO macro. The message consists mainly of EBCDIC information and is in variable-length record format. The format of the area is shown following the descriptions of the SYNADAF parameters. I assume that's Y(count),X'',up to 32,752 bytes of message text. What callers would suffer overruns copying an unexpectdly long message into a static buffer? Would some simply attempt to PUT it, as returned, to SYSTERM and trigger a cascade of similar errors? Regardless, it's lousy, and should be fixed. As reusable code, not only for HLASM. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumps and cancelling jobs
This didn't help. I see no indication that Fault Analyzer was invoked at all. Usually when its invoked, even if the dump is suppressed, FA will write an informational message to the console. This is not happening in this case. Thanks, Frank From: IBM Mainframe Discussion List on behalf of Christopher Y. Blaicher Sent: Friday, April 12, 2019 10:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dumps and cancelling jobs You probably will get what you want with C jobname,DUMP console command, or CD in a SDSF screen. Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, April 12, 2019 12:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dumps and cancelling jobs The discussion about non-recoverable abends and cancelling jobs brings to mind an "issue" I've had since we migrated from z/VSE to z/OS in 2010. If I recall correctly, if a job was cancelled in z/VSE the "dump analysis" product (Abend-Aid, IBM Fault Analyzer, et al) would still get control and produce a nice formatted dump. With z/OS this does not appear to be the case. So if we cancel a job that, for example, appears to be in a infinite loop we have no way to know even where within the program its looping, much less what the program data is. Did we perhaps just miss some option that would allow our dump analysis program to take control when a job is cancelled? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OpenSSH upgrade option
On Fri, 12 Apr 2019 16:54:08 +, Seymour J Metz wrote: >Who says IBM patches? > Read Timothy Sipples's ply. >How could EBCDIC conceivably be relevant? > The ssh command performs ASCII<->EBCDIC conversion (for pedants, 1047<->819). I'd expect that to be IBM-specific. Probably not relevant to security, but additional code that must be supported in an IBM instance, or conditionally bypassed if the sources are merged. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumps and cancelling jobs
I should clarify. If I include a SYSABEND or SYSUDUMP DD in the JCL (which we generally do not do), if I cancel with dump I will get a standard z/OS dump. But the fault analysis tool is still not invoked. From: IBM Mainframe Discussion List on behalf of Frank Swarbrick Sent: Friday, April 12, 2019 11:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dumps and cancelling jobs This didn't help. I see no indication that Fault Analyzer was invoked at all. Usually when its invoked, even if the dump is suppressed, FA will write an informational message to the console. This is not happening in this case. Thanks, Frank From: IBM Mainframe Discussion List on behalf of Christopher Y. Blaicher Sent: Friday, April 12, 2019 10:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dumps and cancelling jobs You probably will get what you want with C jobname,DUMP console command, or CD in a SDSF screen. Chris Blaicher Technical Architect Syncsort, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, April 12, 2019 12:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dumps and cancelling jobs The discussion about non-recoverable abends and cancelling jobs brings to mind an "issue" I've had since we migrated from z/VSE to z/OS in 2010. If I recall correctly, if a job was cancelled in z/VSE the "dump analysis" product (Abend-Aid, IBM Fault Analyzer, et al) would still get control and produce a nice formatted dump. With z/OS this does not appear to be the case. So if we cancel a job that, for example, appears to be in a infinite loop we have no way to know even where within the program its looping, much less what the program data is. Did we perhaps just miss some option that would allow our dump analysis program to take control when a job is cancelled? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OpenSSH upgrade option
> Read Timothy Sipples's ply. That talks about IBM receiving patches, not distributing them. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Friday, April 12, 2019 1:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OpenSSH upgrade option On Fri, 12 Apr 2019 16:54:08 +, Seymour J Metz wrote: >Who says IBM patches? > Read Timothy Sipples's ply. >How could EBCDIC conceivably be relevant? > The ssh command performs ASCII<->EBCDIC conversion (for pedants, 1047<->819). I'd expect that to be IBM-specific. Probably not relevant to security, but additional code that must be supported in an IBM instance, or conditionally bypassed if the sources are merged. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
testing connectivity for send
All apologies. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OpenSSH upgrade option
Right. I was the first to mention "security patches" in this thread, and I was referring to source patches made upstream to he code to fix bugs, CVEs, etc. Also - just because IBM ports a base version (6.4, 7.6), it doesn't mean that they didn't (or won't later) backport bug fixes (security or otherwise) that were made later in the upstream code. On Fri, Apr 12, 2019 at 12:14 PM Seymour J Metz wrote: > > Read Timothy Sipples's ply. > > That talks about IBM receiving patches, not distributing them. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> > Sent: Friday, April 12, 2019 1:06 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: OpenSSH upgrade option > > On Fri, 12 Apr 2019 16:54:08 +, Seymour J Metz wrote: > > >Who says IBM patches? > > > Read Timothy Sipples's ply. > > >How could EBCDIC conceivably be relevant? > > > The ssh command performs ASCII<->EBCDIC conversion (for pedants, > 1047<->819). I'd expect that to be IBM-specific. Probably not relevant > to security, but additional code that must be supported in an IBM > instance, or conditionally bypassed if the sources are merged. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMF Log Blocks
Does anyone have any experience with SMF LOG blocks returned from the IXGBRWSE READCURSOR service. The doc says it returns a block of SMF records . All return codes are good after the IXGCONN and IXGBRWSE START but the returned area does not seem to be SMF data. Am doing a single LOG block request although I did try to use MULTIBLOCKS=YES and the area returned appears the same except for the IXGMBR header area and IXGMBLT area (again, just asked for 1 block). I seem to be missing something here. IBM doc not the greatest on using these services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DASD-only logging
A Coupling Facility Logical Partition can run on shared CPs. It does not require an ICF engine. Normally I would not recommend the use of a CP, but if you are careful not to use the CF a lot, and use DYNDISP=thin, it can be quite useful. If all the connectors to the CF are in the same CEC, then there is no real CF link hardware required. Connecting multiple CECs will require purchasing hardware CF links. G. Tom Russell “Stay calm. Be brave. Wait for the signs” — Jasper FriendlyBear “… and remember to leave good news alone.” — Gracie HeavyHand -Original Message- Date:Wed, 10 Apr 2019 19:05:40 + From:Jesse 1 Robinson Subject: Re: DASD-only logging This box is for DASD mirroring (SDM) and system recovery. It has only one CP except when CBU is fired up. No data host at all under normal circumstances. As modestly priced as a CF might be, I don't think we could sell the idea just for the benefit of sysprogs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OpenSSH upgrade option
On 12/04/2019 5:35 pm, Timothy Sipples wrote: Paul Jodlowski wrote: Currently OpenSSH is at 6.4p1, I have been asked by our Network Security Team to upgrade to OpenSSH 7.4. That's an "amusing" recommendation from your Network Security Team. Unless security patches have been backported and applied to a particular distribution of OpenSSH, OpenSSH 7.4p1 has at least three known security vulnerabilities that I see: CVE-2018-15919, CVE-2018-15473, and CVE-2017-15906. So is your Network Security Team running around and getting lots of other systems "updated" to an insecure release of OpenSSH (7.4), if those other systems don't have backported security patches? Probably. Ooops. As far as I can see those CVEs also apply to 6.4p1. How would you go about verifying that they had been fixed in z/OS ssh? Suggesting that their existence means that 7.4 is insecure (more so than 6.4p1) seems very misleading to me. Looking at the CVE list, I can guess that the security team might be interested in the more severe CVEs applying to ssh before 7.4, e.g. CVE-2016-10010, CVE-2016-10012. How would you verify that the fixes are applied to z/OS 6.4p1? (Reading between the lines the changes sound significant enough to make backporting unlikely.) Andrew Rowley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
