Re: "XYZZY"?
For 50 years, I've always used the five syllable pronunciation. Dave Cole At 8/24/2023 05:21 PM, Bob Bridges wrote: It's only just now occurring to me to wonder: How should "XYZZY" be pronounced? I've always said "KSIZZ-ee", but it occurs to me now that there are other possibilities. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* The thing that most Europeans simply do not grasp is the size of the US. From where I lived in Wiesbaden, Germany, I could drive for six hours in any direction and be in almost any country in Europe -- excepting Spain, Greece, and maybe Norway/Sweden depending on ferry connections. You can drive in the US for six hours and still be in west Texas. -Charley Seavey in the Patrick O'Brian discussion forum (http://www.wwnorton.com/forums/POB/POBforum.htm), May 2000. */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kurt Quackenbush Sent: Thursday, August 24, 2023 16:47 > Yes.&whatever. As I wrote before, there's way too much "take this job and find the 27 places that say XYZZY and change them to the right HLQ." instead of -- 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
I don’t pay attention to anyone but Kurt Quackenbush when it comes to SMPe. He’s the expert. Sent from Yahoo Mail for iPhone On Sunday, August 27, 2023, 12:16 AM, Tom Brennan wrote: By themselves, probably few here would care. But you used M=Maintenance and the 1MB limit as part of your comparison of SMP/E vs. Linux install methods. That's when it becomes more of a problem. On 8/26/2023 8:39 PM, Jon Perryman wrote: > I grant you that M stands for Modification and that some PTF's are greatly > exceeding 1MB but do you consider these consequential. -- 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
By themselves, probably few here would care. But you used M=Maintenance and the 1MB limit as part of your comparison of SMP/E vs. Linux install methods. That's when it becomes more of a problem. On 8/26/2023 8:39 PM, Jon Perryman wrote: I grant you that M stands for Modification and that some PTF's are greatly exceeding 1MB but do you consider these consequential. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
> On Saturday, August 26, 2023 at 08:05:31 PM PDT, Tom Brennan > wrote: > A bigger problem is Jon says things like this with such conviction and > authority that other people reading these posts, perhaps years from now, > will think they are true. I grant you that M stands for Modification and that some PTF's are greatly exceeding 1MB but do you consider these consequential. Sorry for thinking maintenance when manuals say installation and maintenance but only use the acronym. As for PTF's far greater than 1MB, the physical size is actually inconsequential. More to the point is that very rately bundles more than 1 problem into a PTF unless things have changed. I haven't seen IBM PTF's in many years. Tell us what you disagree with that is of actual consequences. I doubt that years from now, people will bother looking at these postings. On Saturday, August 26, 2023 at 08:05:31 PM PDT, Tom Brennan wrote: A bigger problem is Jon says things like this with such conviction and authority that other people reading these posts, perhaps years from now, will think they are true. On 8/26/2023 7:31 PM, David Spiegel wrote: > Hi Jon, > You said: "...The M in SMP/e stands for Maintenance ..." > This statement has NEVER been true. > The M is an abbreviation of Modification and it has ALWAYS been this way. > > Regards, > David > -- 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
He has a future in politics. Sent from Yahoo Mail for iPhone On Saturday, August 26, 2023, 11:05 PM, Tom Brennan wrote: A bigger problem is Jon says things like this with such conviction and authority that other people reading these posts, perhaps years from now, will think they are true. On 8/26/2023 7:31 PM, David Spiegel wrote: > Hi Jon, > You said: "...The M in SMP/e stands for Maintenance ..." > This statement has NEVER been true. > The M is an abbreviation of Modification and it has ALWAYS been this way. > > Regards, > David > -- 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
A bigger problem is Jon says things like this with such conviction and authority that other people reading these posts, perhaps years from now, will think they are true. On 8/26/2023 7:31 PM, David Spiegel wrote: Hi Jon, You said: "...The M in SMP/e stands for Maintenance ..." This statement has NEVER been true. The M is an abbreviation of Modification and it has ALWAYS been this way. Regards, David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
Hi Jon, Another misspeak ... You said: " ...You never see a PTF that is 1MB. ..." I've seen PTFs that are a lot bigger than 1 Mb. Regards, David On 2023-08-25 21:55, Jon Perryman wrote: On Thursday, August 24, 2023 at 11:57:33 AM PDT, Steve Thompson wrote: With Linux distros there are a few maint systems. The one I am most familiar with is RPM. Linux (nor Unix) does NOT have any maint systems. P in RPM stands for Package which is the z/OS equivalent of product / component. Complete packages are replaced regardless of the problems you want to fix. Every package has a version number which is indentifies all the maintenance included in that package. To me YAST (the Linux equivalent of SMP/E) handles upgrades YAST and SMP/e have nothing in common. YAST tells you it's about installation and configuration. It's about replacing the entire package and nothing to do with maintaining that package. The M in SMP/e stands for Maintenance. You never see a PTF that is 1MB. The only reason SMP/e installs, is to create a maintenance environment for the product / component. If installation is your only requirement, then use a different tool like IEBCOPY, DFDSS or ???. Each product/component has its own main entry and dependencies. Unix dependencies are by version number and have nothing to do with the package (product/component) in question. The package is completely replaced. SMP/e dependencies can be for entities within the same function, other functions, PTFs and APARs. A function is the SMP/e equivalent of a Unix package. I thought it was a fairly good replacement for SMP/E for the Linux side of things. I can see how it could be used to do z/OS and related. YAST, RPM and other Unix package installers are unacceptable replacements for SMP/e. Name 1 z/OS customer that is willing to risk reinstalling an entire product/component because they need 1 PTF. Add to that cascading product installs because of dependencies. Worse than that, testing must include everything that changed in those installs and every product/component that interacts with all the installed products/components. I think z/OS uptime is 99.%. You get what you pay for. Unix maint philosophy may be acceptable on $10,000 computers but highly unacceptable on multi-million $ computers. We don't tolerate unintentional downtime. -- 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
Hi Jon, You said: "...The M in SMP/e stands for Maintenance ..." This statement has NEVER been true. The M is an abbreviation of Modification and it has ALWAYS been this way. Regards, David On 2023-08-25 21:55, Jon Perryman wrote: On Thursday, August 24, 2023 at 11:57:33 AM PDT, Steve Thompson wrote: With Linux distros there are a few maint systems. The one I am most familiar with is RPM. Linux (nor Unix) does NOT have any maint systems. P in RPM stands for Package which is the z/OS equivalent of product / component. Complete packages are replaced regardless of the problems you want to fix. Every package has a version number which is indentifies all the maintenance included in that package. To me YAST (the Linux equivalent of SMP/E) handles upgrades YAST and SMP/e have nothing in common. YAST tells you it's about installation and configuration. It's about replacing the entire package and nothing to do with maintaining that package. The M in SMP/e stands for Maintenance. You never see a PTF that is 1MB. The only reason SMP/e installs, is to create a maintenance environment for the product / component. If installation is your only requirement, then use a different tool like IEBCOPY, DFDSS or ???. Each product/component has its own main entry and dependencies. Unix dependencies are by version number and have nothing to do with the package (product/component) in question. The package is completely replaced. SMP/e dependencies can be for entities within the same function, other functions, PTFs and APARs. A function is the SMP/e equivalent of a Unix package. I thought it was a fairly good replacement for SMP/E for the Linux side of things. I can see how it could be used to do z/OS and related. YAST, RPM and other Unix package installers are unacceptable replacements for SMP/e. Name 1 z/OS customer that is willing to risk reinstalling an entire product/component because they need 1 PTF. Add to that cascading product installs because of dependencies. Worse than that, testing must include everything that changed in those installs and every product/component that interacts with all the installed products/components. I think z/OS uptime is 99.%. You get what you pay for. Unix maint philosophy may be acceptable on $10,000 computers but highly unacceptable on multi-million $ computers. We don't tolerate unintentional downtime. -- 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: Is SMP/E needed for installs?
On Saturday, August 26, 2023 at 11:17:39 AM PDT, Phil Smith III wrote: > I'm not really going to tell a customer, "I'm sorry, you're clearly not up to > the job > of installing this product. Who else there knows more than you do?" so I'm > not > sure what your real-world point is-IOW, what different action you're > suggesting. The customer isn't being rude and they deserve to be educated in a polite way. You get them to come to the realization on their own by asking them questions about planning, recovery and other system critical information. More often than not, these people are trying to learn, be independent and prove themselves but they don't know what they don't know. Your questions will open the door for them to ask intelligent questions from their lead. A good lead will recognize they did not educate this person on their policies and strategies. > PSWI? Pharmacy Society of Wisconsin? PSWI (Portable Software Instance) that has been mentioned a few times in this thread. It's the first time I heard about it too and I don't know anything about it. If I understand it correctly, it's IBM's new alternative product installer that guides a user thru the complete install, setup and configuration process. I suspect that it includes SMP/e steps. I would need to see it but I'm leery that it will cause people to ignore recovery that needs to be planned during installation of products. >>You say EDIT CHANGE ALL instances is causing customers grief. Do you > Again, don't disagree that they don't understand, but?? If a customer is complaining about changing the JCL, then they are complaining that it's tedious. While they are right, we also know that they are ignoring the planning and company policies. They can easily create an edit exec with all the change commands. > But if I make the changes (via automation) and it screws up, it's my fault. > If I gave them something that won't run as provided, and > they make changes and it screws up, it's their fault. This matters. What makes you think you screwed up? This is z/OS with all it's nuances. Automation can only get the customer in the ball park but their company policies dictate what they must change by hand. Do certain files require SYS1? How about impact of recovery? What about disaster recovery? How do they manage SMP/e CSIs so that libraries remain consistent. This isn't VM or Linux where everything is consistent. As a z/OS product developer, you can't ask questions to cover every situation. VM and Linux are limited to 1 system z where as z/OS sysplex can encompass 32 system z. > When they do get it wrong, SMP/E errors are usually incomprehensible. > I've said this repeatedly; are some of my posts not getting through? I see > them. I stopped watching the list for a while so I probably missed them. If by SMP/e errors, you mean SMP/e messages, then is the SMP/e message manual not helpful? Are the actions you need to take unclear in the message manual? Is the terminology a problem? Is it a problem finding utility output in the job? Are the errors reported by the customer to you or are they problems with SMP/e statements? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Syncsort > DFsort migration
>>., an application sort execution, such as SAS-invoked PROC SORT under DFSORT >>does not exploit zSORT/SORTL (SAS INSTITUTE responded "not planned >>enhancement, and customers are not asking for it either.") Scott, Program invoked Sorts can exploit zSORT/SORTL if DFSORT can do the reads and writes. So, passing SORTDD= via parameter list will help to ensure that you can use zsort if you don't run into any other restrictions. >- unsure about how a "new" DFSORT site Any specific reason for using the word "new" ? DFSORT site has been the same for a long time. https://www.ibm.com/support/pages/dfsort or ibm.com/storage/dfsort ( will be re-directed to first link) is generally updated with every release or with any new enhancements. >> converting from use of PGM=SYNCSORT, PGM=SYNCGENR, PGM=SYNCTOOL, will "under >> the covers via a program alias" will get the DFSORT-equivalent - surely >> there must be some documented knob-turning with DFSORT >> install/implementation at IBM.COM ?? DFSORT doesn't have "under the cover" aliases for the other product, but will provide the necessary JCL to create the alias if requested. Thanks, Kolusu DFSORT Development IBM Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server
There's a free "wireshark" for z/OS. Something like NBOS for z/OS > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jerry Whitteridge > Sent: Saturday, August 26, 2023 10:47 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server > > [EXTERNAL EMAIL] > > Thanks Charles I was just starting to look at if curl would do it. > > This is a TN3270 server on z/OS that I want to check what cert it is > presenting > to the user for a TLS connection. > > J > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Charles Mills > Sent: Saturday, August 26, 2023 10:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server > > Well, I wrote a product that does exactly that in a beautiful graphic fashion > and > is part of NewEra's ICEDirect suite. > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.com%2Fv3%2F__https%3A%2F%2Fwww.newera.com%2FINFO%2FIC > EDirect.pdf__%3B!!JmPEgBY0HMszNaDT!p7XN4J09CBWP5eaGgpdT2VAVnTc > gOHI66aUmtmicKPvG- > 4oXEGRcKDnH9yb_2KRZQg0s99_3guSOoyqqicnIdvXILxNY%24&data=05%7C > 01%7CGIBNEY%40WSU.EDU%7C0436f4fd6f0d41e45b3608dba65c7453%7C > b52be471f7f147b4a8790c799bb53db5%7C0%7C0%7C638286688235202 > 429%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4NW > Vk9ZbssYTQSffyGgNsMixH22r32oxKNNzbLUJgCA%3D&reserved=0 > > Does that count? > > For free tools > > 1. Is it a Web server? If so most browsers will display the server > certificate and > the entire chain of trust. Click on the padlock icon next to the URL and take > it > from there. > > 2. Perhaps you can do this with OpenSSL? I think so but don't know the > details. > > 3. Can you do this with curl? Seems likely but I am not a curl expert. > > Charles > > On Sat, 26 Aug 2023 16:52:46 +, Jerry Whitteridge > wrote: > > >I used to use a java command to check on my certs on the mainframe > > > >keytool -printcert -sslserver :port > > > >but now all I get is a message > > > >XXX:/u/xxx:>keytool -printcert -V -sslserver .yyy.com > >keytool error: java.lang.Exception: No certificate from the SSL server > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > Warning: All e-mail sent to this address will be received by the corporate e- > mail system, and is subject to archival and review by someone other than the > recipient. This e-mail may contain proprietary information and is intended > only > for the use of the intended recipient(s). If the reader of this message is > not the > intended recipient(s), you are notified that you have received this message in > error and that any review, dissemination, distribution or copying of this > message is strictly prohibited. If you have received this message in error, > please notify the sender immediately. > > > -- > 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: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
> On Friday, August 25, 2023 at 09:32:34 PM PDT, Joel C. Ewing > wrote: > in that sense a package is similar to an FMID of a z/OS product; A Unix package name combined with the version is an SMP/e FMID. Just like Unix, a z/OS will have 1 or more FMID. Like Unix, installing 1 of the FMIDs will automatically cause the related/dependant FMIDs to be installed. > There isn't really any direct equivalence between RPM and SMP/E > concepts of maintenance. I repeat, RPM installs packages that has nothing to do with maintenance. The Unix maintenance philosophy is to create multiple smaller packages in the hopes that a single package is less of an impact than reinstalling the entire product. In SMP/e, we can use 1 FMID instead of worrying about maintenance philosophy. > Since a large Linux application (like LibreOffice) may be packaged as > several interdependent packages, but the number of pieces/files contained in a > package tends to vary more widely than for z/OS products, in some cases > containing very few files. Ask yourself why a package with just a few files that could have been included with another package. The one question you don't answer is what goes into your packaging decisions. What are the benefits to creating multiple packages/FMIDs versus 1 large package/FMID? > but new release levels of a package also occur with much greater > frequency than new versions or release levels of a z/OS product. > A new release level of a package typically contains a number of code fixes, > and in that respect is more like a z/OS PTF that fixes multiple APARS. IBM is on a 2 year package / FMID release cycle. Are you saying that z/OS would be manageable where PTFs become available every 2 years? > current RPM download protocols also support just downloading the RPM delta > from the previous package level if only a small part of a large package RPM > file > has changed. Installing changed files versus installing the entire package doesn't change anything except speeding up the process. The new package has been installed completely. > the dependency requirements are simpler to resolve when there are > only package-level dependencies to consider. Dependency resolution is the same for RPM and SMP/e. Neither is complicated for the user. >The frequency of occurrence of new package releases with minor changes > definitely entitles this to be called a maintenance process. Frequency of packaging is the maintenance process. If you change to 20 year packaging frequency, you wouldn't call this maintenance. The process (not RPM) is the maintenance philosophy. > The decentralized nature of Linux package maintenance Linux and RPM are free. Both are basic solutions to a problem. Unlike z/OS, a Linux image is only active on 1 physical machine. Maintenance is applied directly to the active system. A $10,000 machine being down for a couple hours is trivial. Google has 5,500,000 servers so missing 10,000 servers would go unnoticed. On the other hand a multi-million $ sysplex will be catastrophic. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM 99.999999% availability was: RPMs for installs and Maint
> On Saturday, August 26, 2023 at 02:18:12 AM PDT, David Crayford > wrote: > My bank runs a mainframe and I couldn’t use internet banking > when abroad because they were running month-end scheduled maintenance. You're naive if you think this had anything to do with z/OS regular scheduled system maintenance. It's been many years but it was extremely rare that I needed to shutdown every LPAR in a sysplex at one time. I've known companies that always disable access for a specific timeslot so that customers are accustomed to the downtime in the off-chance the time is actually needed for some reason. More likely it was something to do with an app that needed to move data starting a new month. Maybe it was being over cautious but it's ridiculous to say this was about z/OS being down. >> On 26 Aug 2023, at 9:55 am, Jon Perryman wrote: >> I think z/OS uptime is 99.%. > I don’t think so. IBM claim 99.999% single server uptime for z and that’s > just the hardware. You are confusing the definition for Hardware and software uptime because they have very different definitions and meanings. More important, you don't understand the difference between "single z/OS server", "single Linux server" and "single lpar". I've worked on High Availability solutions that can get a little flexible in terminology. For instance, SAP HA can cancel a few inflight transactions during recovery but it's still considered fully functional for the entire time. A z/OS sysplex is a single server unless a customer chooses not to be. Hardware is typically identical for all LPARs in a z/OS sysplex and workload is shifted according to definitions. Linux on the other hand requires you to jump through hoops with additional software to achieve similar results. I couldn't find z/OS availability but at https://www.ibm.com/z/resiliency, IBM says Linux is 99.99%. z/OS must be at least the same. Why do you doubt IBM's claiming 99.999% system z uptime especially considering their automated hardware recovery and hotswap? Hardware uptime is calculated using equipment MTBF, life expectancy, number of machines and probably more but excludes downtime due to customers choice. 99.999% is a believable number especially compared to non-IBM equipment. > That’s the same as they claim for POWER running either AIX or Linux > on RedHat Open Shift and what HP claim for Superdomes running HP-UX. > They all claim higher then five-nines running in clusters. z/OS is not a cluster solution. It doesn't rely on data replication nor servers to provide common access to data. It doesn't require a server to assign workload although it does rely upon a coupling facility for intercommunications between LPARs. A z/OS lpar is a fully functional entity that participates within the sysplex. IBM says eight-nines for Linux on system z and I suspect they mean clustering. This is well beyond the five-nines of AIX or HP-UX. Still, as you say, these require implementing clustering which is not out of the box as simple as z/OS sysplex for customers. > Many providers claiming five-nines availability will add small print to get > around this problem. > By excluding scheduled downtime, five-nines becomes a lot easier. This is absurd. You never schedule every LPAR in the Sysplex shutdown except on the very rare occasion that there is a compatibility issue. IBM is not guaranteeing you eight-nines availability because they do not have complete control. IBM has set high expectations for their z/OS customers, and this affects OEM product developers too. The worst call I took involved 35 managers screaming at me because they thought my product trashed one z/OS LPAR. Imagine how bad it would have been if the entire sysplex was trashed. It turns out that another product did a storage stomp on my address space which was vital to the entire z/OS LPAR. >> You get what you pay for. Unix maint philosophy may be acceptable on $10,000 >> computers >> but highly unacceptable on multi-million $ computers. We don't tolerate >> unintentional downtime. > That doesn’t stand up to scrutiny! Just ask Air New Zealand in 2009, HSBC in > 2011, > or the Royal Bank of Scotland in 2013. Again with absurd statements. If you crash your car, do you claim it's a manufacturing defect? Without details, we have no clue if these are relevant. These companies will take steps to ensure this doesn't happen again. On a $10,000 computer, they will ignore it and do business as usual. > The fact is that even five-nines availability for an entire computing service > is impossible to guarantee. No one is offering a guarantee, but eight-nines availability is doable when planned correctly. No one can stop customers from compressing the active sys1.linklib. No one can stop customers from hiring unqualified people. > There is too little room for error and Black Swan or unexpected events are > impossible to eliminate. There is plenty of room for error but you have
Re: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server
Can you set the date back on the PC? CM On Sat, 26 Aug 2023 18:06:36 +, Jerry Whitteridge wrote: >Unfortunately my system is responding expired cert and drops the connection >before I can do that - which is why I'm trying to get the cert details -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server
Try this, see if it gets you what you need. curl https://example.com -vI Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com --- Original Message --- On Saturday, August 26th, 2023 at 2:06 PM, Jerry Whitteridge wrote: > Unfortunately my system is responding expired cert and drops the connection > before I can do that - which is why I'm trying to get the cert details > > J > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Charles Mills > > Sent: Saturday, August 26, 2023 11:03 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server > > In my emulator if I click on the padlock icon I get > > OpenSSL Version: OpenSSL 1.0.1g 7 Apr 2014 > Encryption: AES256-GCM-SHA384 - 256 bits > Protocol: TLSv1.2 > Issued By: DigiCert Inc > Organization: International Business Machines Corporation > Distinguished Name: unknown > Department: unknown > Country: US > State/Province: New York > City: Armonk > Domain: dtsc.dfw.ibm.com > Valid: From 2023-04-05 00:00:00 to 2024-04-04 23:59:59 > > This is with Tom Brennan's Vista. Your mileage may vary. > > Charles > > On Sat, 26 Aug 2023 17:46:44 +, Jerry Whitteridge > jerry.whitteri...@albertsons.com wrote: > > > Thanks Charles I was just starting to look at if curl would do it. > > > > This is a TN3270 server on z/OS that I want to check what cert it is > > presenting to the user for a TLS connection. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > Warning: All e-mail sent to this address will be received by the corporate > e-mail system, and is subject to archival and review by someone other than > the recipient. This e-mail may contain proprietary information and is > intended only for the use of the intended recipient(s). If the reader of this > message is not the intended recipient(s), you are notified that you have > received this message in error and that any review, dissemination, > distribution or copying of this message is strictly prohibited. If you have > received this message in error, please notify the sender immediately. > > > -- > 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: Is SMP/E needed for installs?
Jon Perryman wrote: >Sorry, I should have been clear that "we" refers to product >developers. After 40 years, the SMP/e install jobs haven't >significantly changed to make things automatically change. We have the >tools, but we choose to have people modify the JCL even today. We >don't want customers to automate the process. >Customers shouldn't automate these tasks but not having these skills >tells us they should not be installing z/OS because they don't have >experience with z/OS planning, recovery and other required skills. >Simply put they need guidance because automating the installation >ignores things they don't understand. >The SMP/e install jobs are the easy part. Customers who get confused >at this stage don't know their company z/OS strategy and are a danger. >It's been many years since my last z/OS install but understanding and >setting the strategy many times required changes to the install jobs. >Target & dist datasets and CSI's have an impact on recovery, disaster >recovery and much more. If someone is confused during install, then >they were overwhelmed during planning. I don't disagree, but I'm not really going to tell a customer, "I'm sorry, you're clearly not up to the job of installing this product. Who else there knows more than you do?" so I'm not sure what your real-world point is-IOW, what different action you're suggesting. >It's absurd to say updating jobs automatically creates a maze for the >customer. CA has successfully used it for many years and IBM has PSWI. >I think they put you into edit of each job that you submit. From my >perspective, this encourages the uninitiated to submit the job without >reviewing the job. They have a false sense of reality because they are >not spending time changing the JCL. PSWI? Pharmacy Society of Wisconsin? CA has built essentially a whole product for product installation and maintenance. They have (or at least had) the manpower to do that. I don't. >You say EDIT CHANGE ALL instances is causing customers grief. Do you >think these people understand their companies z/OS strategy, planning, >recovery and more? SMP/e is not the point of grief. z/OS is so stable, >many customers don't consider the impact of not choosing wisely during >install on when it goes live. Again, don't disagree that they don't understand, but?? >Just write a REXX exec that updates every JCL because customer coding >accomplishes the same results. In both cases, the customers is going >to blindly submit the job with the false impression you made the right >choices for their environment. But if I make the changes (via automation) and it screws up, it's my fault. If I gave them something that won't run as provided, and they make changes and it screws up, it's their fault. This matters. >What SMP/e error handling are you recommending? Everything I'm hearing >is confusion and annoyance about changing all occurrences in JCL. This >has nothing to do with SMP/e. When they do get it wrong, SMP/E errors are usually incomprehensible. I've said this repeatedly; are some of my posts not getting through? I see them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server
Unfortunately my system is responding expired cert and drops the connection before I can do that - which is why I'm trying to get the cert details J -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Saturday, August 26, 2023 11:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server In my emulator if I click on the padlock icon I get OpenSSL Version: OpenSSL 1.0.1g 7 Apr 2014 Encryption: AES256-GCM-SHA384 - 256 bits Protocol:TLSv1.2 Issued By: DigiCert Inc Organization:International Business Machines Corporation Distinguished Name: unknown Department: unknown Country: US State/Province: New York City:Armonk Domain: dtsc.dfw.ibm.com Valid: From 2023-04-05 00:00:00 to 2024-04-04 23:59:59 This is with Tom Brennan's Vista. Your mileage may vary. Charles On Sat, 26 Aug 2023 17:46:44 +, Jerry Whitteridge wrote: >Thanks Charles I was just starting to look at if curl would do it. > >This is a TN3270 server on z/OS that I want to check what cert it is >presenting to the user for a TLS connection. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server
In my emulator if I click on the padlock icon I get OpenSSL Version: OpenSSL 1.0.1g 7 Apr 2014 Encryption: AES256-GCM-SHA384 - 256 bits Protocol:TLSv1.2 Issued By: DigiCert Inc Organization:International Business Machines Corporation Distinguished Name: unknown Department: unknown Country: US State/Province: New York City:Armonk Domain: dtsc.dfw.ibm.com Valid: From 2023-04-05 00:00:00 to 2024-04-04 23:59:59 This is with Tom Brennan's Vista. Your mileage may vary. Charles On Sat, 26 Aug 2023 17:46:44 +, Jerry Whitteridge wrote: >Thanks Charles I was just starting to look at if curl would do it. > >This is a TN3270 server on z/OS that I want to check what cert it is >presenting to the user for a TLS connection. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retrieving Certificate details from a server
Maybe openssl s_client -connect host:port -showcerts Charles On Sat, 26 Aug 2023 12:41:57 -0500, Charles Mills wrote: snip >2. Perhaps you can do this with OpenSSL? I think so but don't know the >details. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server
Thanks Charles I was just starting to look at if curl would do it. This is a TN3270 server on z/OS that I want to check what cert it is presenting to the user for a TLS connection. J -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Saturday, August 26, 2023 10:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL EMAIL: Re: Retrieving Certificate details from a server Well, I wrote a product that does exactly that in a beautiful graphic fashion and is part of NewEra's ICEDirect suite. https://www.newera.com/INFO/ICEDirect.pdf Does that count? For free tools 1. Is it a Web server? If so most browsers will display the server certificate and the entire chain of trust. Click on the padlock icon next to the URL and take it from there. 2. Perhaps you can do this with OpenSSL? I think so but don't know the details. 3. Can you do this with curl? Seems likely but I am not a curl expert. Charles On Sat, 26 Aug 2023 16:52:46 +, Jerry Whitteridge wrote: >I used to use a java command to check on my certs on the mainframe > >keytool -printcert -sslserver :port > >but now all I get is a message > >XXX:/u/xxx:>keytool -printcert -V -sslserver .yyy.com >keytool error: java.lang.Exception: No certificate from the SSL server -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Retrieving Certificate details from a server
Well, I wrote a product that does exactly that in a beautiful graphic fashion and is part of NewEra's ICEDirect suite. https://www.newera.com/INFO/ICEDirect.pdf Does that count? For free tools 1. Is it a Web server? If so most browsers will display the server certificate and the entire chain of trust. Click on the padlock icon next to the URL and take it from there. 2. Perhaps you can do this with OpenSSL? I think so but don't know the details. 3. Can you do this with curl? Seems likely but I am not a curl expert. Charles On Sat, 26 Aug 2023 16:52:46 +, Jerry Whitteridge wrote: >I used to use a java command to check on my certs on the mainframe > >keytool -printcert -sslserver :port > >but now all I get is a message > >XXX:/u/xxx:>keytool -printcert -V -sslserver .yyy.com >keytool error: java.lang.Exception: No certificate from the SSL server -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Retrieving Certificate details from a server
I used to use a java command to check on my certs on the mainframe keytool -printcert -sslserver :port but now all I get is a message XXX:/u/xxx:>keytool -printcert -V -sslserver .yyy.com keytool error: java.lang.Exception: No certificate from the SSL server Does anyone have another tool that can provide the same info ? Jerry Whitteridge Sr Manager Managed Services jerry.whitteri...@albertsons.com 480 578 7889 Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Syncsort > DFsort migration
On Sat, 26 Aug 2023 11:52:58 +, Richard McIntosh wrote: >We are starting to do a very rushed syncsort to DFsort migration. >I am assuming most of the sort ports are identical, but I bet not all of them. >Does anyone have a list of parms that need to be looked at? >Or anything thing else that I should be aware of. > >Thanks in advance for your time in replying. > >Richard M Some relevant points/considerations/concerns: - SYNCSORT (now SYNCSORT MFX re-branded with Precisely marketing over-reach) use of /$ORTPARM DD (e.g., ELAP, VSCORE/VSCORET, others) and DFSORT uses //SORTCNTL DD or //DFSPARM DD - clearly may involve external JCL-changes. - DFSORT generates enhanced SYSOUT diagnostics when //SORTDIAG DD DUMMY coded; otherwise with SYNCSORT uses $ORTPARM DD control parameters - "out of the box" DFSORT ICEMAC definitions pretty well tuned; otherwise unsure about current-methodology with SYNCSORT. - SYNCSORT (namely ZPSaverSuite) may have zIIP-offload exploitation; otherwise, DFSORT not-so-much - an IBM-declared statement, presumed that the z15/z16 zSORT/SORTL on-chip approach taken, but only "compliant" SORT-executions (e.g., an application sort execution, such as SAS-invoked PROC SORT under DFSORT does not exploit zSORT/SORTL (SAS INSTITUTE responded "not planned enhancement, and customers are not asking for it either.") - unsure about "native SORT" using SYNCSORT (more current release/version/maintenance) and z15/z16 zSORT/SORTL (Accelerator). - SYNCSORT may be implemented with SAS application PROC SYNCSORT; otherwise SAS PROC SORT using DFSORT calls for SAS CONFIG parameter SORTBLKMODE. - DB2 sort-operation considerations - unknown about if/how/where SYNCSORT might get invoked; otherwise, with DFSORT consider IBM PH03207 and later documentation available for z15/z16 zSORT/SORTL exploitation. - unsure about how a "new" DFSORT site, converting from use of PGM=SYNCSORT, PGM=SYNCGENR, PGM=SYNCTOOL, will "under the covers via a program alias" will get the DFSORT-equivalent - surely there must be some documented knob-turning with DFSORT install/implementation at IBM.COM ?? - z/OS address space control/mgmt of REGION / MEMLIMIT (job- and job-step level) influences how a HOST-SORT solution can exploit memory over disk for SORT-WORK operations. - With a DFSORT implementation, active SMF type 16 (especially pay attention to DFSORT complaining when it cannot exploit zSORT/SORTL for whatever reason); otherwise, SYNCSORT has some near-equivalent sort invocation/performance data source when implemented with the SMF=(ON,nnn|208) parameter. - Likely both SYNCSORT and DFSORT behave as-expected when SORT-WORK allocations are made dynamically; otherwise consider HOST-SORT behavior when JCL-coded SORT-WORK DD allocations are made/used (e.g., DSNTYPE=LARGE, no VOL-ADD support for either DFSORT or SYNCSORT. Again, coding //SORTDIAG DD DUMMY will enhance the diagnostic-messages output sent to //SYSOUT DD for DFSORT operations (unsure if SYNCSORT has a special DD-name opportunity or otherwise is only driven with $ORTPARM DD override with MSG= parameter coding technique.) - by all means affordedexploit / engage available IBM/ISV/vendor SUPPORT services to ensure your solution implementation is as optimized as possible -- fortunately both IBM DFSORT and PRECISELY SYNCSORT technical support teams are always very helpful, in my past experience. Scott Barry SBBTech LLC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TS1170
FWIW the TS1160 was shipped in 2018 but not supported in TS7700 until last year in, if I remember correctly, R5.3 microcode. I suspect that adding TS1160 support was at least as much to do with withdrawal of the TS1150 from marketing at the end of 2022. On Fri, 25 Aug 2023 at 21:00, Radoslaw Skorupka < 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > Yes, it is knowledge in *current* documentation. > TS1170 is *very fresh* topic. Almost no IBM source mention it. > Even official PDF leaflet links to details on a page which not yet exists. > However I'm pretty sure the TS1170 will be supported by VTS. > > BTW: few years ago Fujifilm and IBM informed they achieved 580 TB per > cart density. > It doesn't mean product or cart, it means just areal density. > Now we have "only" 50TB. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > W dniu 25.08.2023 o 19:44, Nigel Morton pisze: > > I think the latest drive supported for TS7700 attachment is still the > > TS1160. > > > > On Thu, 24 Aug 2023 at 21:05, Radoslaw Skorupka < > > 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > > > >> FYI IBM released new tape drive. > >> TS1170 with new media JF gives 50TB (150TB) per cart. > >> A previously, the only form of mainframe (FICON) attachment is TS7700 > >> aka VTS. > >> AFAIK the speed is not increased - it is "only" 400MB/s > >> > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> -- > >> 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: Setup Filezila for MF to PC transfers
On Sat, 26 Aug 2023 08:14:48 -0700, Lizette Koehler wrote: > >I am hoping someone is using Filezila that can help me with a configuration >issue. > Filezila server or client? >Everything is working well. Only challenge I have is getting FZ to use my >TSOID for mainframe datasets. > Which is "remote" and which is "local"? >Currently it keeps using uss file names in the remote directory > Desktop "directory" or OMVS "directory"? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Setup Filezila for MF to PC transfers
Lizette: Use this as your remote site HLQ in Filezilla: /_'.' where '' is the desired TSO/E userid or catalog HLQ like SYS2. Filezilla eats the quotes and then lists all data sets cataloged under that userID or HLQ. You can use the 'File manager' option under the 'File' menu to set that as your default remote directory. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Setup Filezila for MF to PC transfers
Dearest List I am hoping someone is using Filezila that can help me with a configuration issue. Everything is working well. Only challenge I have is getting FZ to use my TSOID for mainframe datasets. Currently it keeps using uss file names in the remote directory I have tried 'tsoid' 'tsoid.' tsoid tsoid. And other variations in remote directory. I am sure there is a trick I am missing. Each variation is met with unable to parse directory name If someone has FZ working for Mainframe datasets and could share the secret, That would be amazing. I have been through the PDF, and Wiki and all seem to indicate that FZ should be able to do this I am not sure if I need to set up a network drive to my mf or other actions Thanks for any guidance Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Syncsort > DFsort migration
>> We are starting to do a very rushed syncsort to DFsort migration. Richard, Thank you for your interest in migrating to DFSORT. I will send you an offline mail with a couple of attachments which describes in detail about the parms and the needed changes. Thanks, Sri Hari Kolusu DFSORT Development IBM Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
A curosity question about IHAETD macro
Hello -.A curiosity question about IHAETD macro of SYS1.MACLIB. . ETDHFLAG DS B All non-used bits must be zero. @ ETDRCRD EQU X'80' If bit is ON, NO recording of cross @ * memory connections will be performed. * If bit is OFF, recording will be done. * Classification: DMTI . There is a field ETDHFLAG with an equate ETDRCRD in IHAETD. The comment states: if the bit is ON, no recording of cross memory connections will be performed - . How is this bit set OFF/ON ? When is this bit set OFF/ON ? What determines when this bit is turned OFF/ON ? Where is the data written to/stored? What information is collected ? Can an authorized user program set this Flag before the ETCRE macro is issued ? . Is there any additional documentation on this field other than the macro itself ? . Curious minds want to know.paul.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Syncsort > DFsort migration
We are starting to do a very rushed syncsort to DFsort migration. I am assuming most of the sort ports are identical, but I bet not all of them. Does anyone have a list of parms that need to be looked at? Or anything thing else that I should be aware of. Thanks in advance for your time in replying. Richard M -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "XYZZY"?
Some people say Syz-R-gy. Actually mostly people from the East coast do that. On the west cost they typically call us "SYN-R-GY'. Once they hear me say it a couple times, they tend to at least get a little closer. We used to have a little pronunciation area on our cards just after the big red and black SYZYGY, but thankfully they stopped doing that when we went to the light up and then the current (sort of) 3-D hologram cards. It's actually kind of funny because the background of the cards is an old fashion system dump that has the hex characters that spell out 'If you used Syzygy, this dump would never have happened'. Most people look at the right hand side of the dump and think that the hex characters on the left are being spelled out as something completely different than it actually states. Only one person has caught the discrepancy, and I think he was drunk at that time. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RPMs for installs and Maint: [WAS SMP/E needed for installs?]
> On 26 Aug 2023, at 9:55 am, Jon Perryman wrote: > > I think z/OS uptime is 99.%. I don’t think so. IBM claim 99.999% single server uptime for z and that’s just the hardware. That’s the same as they claim for POWER running either AIX or Linux on RedHat Open Shift and what HP claim for Superdomes running HP-UX. They all claim higher then five-nines running in clusters. What this boils down to is there is redundancy in the hardware for PDUs, Network card, I/O adapters. My bank runs a mainframe and I couldn’t use internet banking when abroad because they were running month-end scheduled maintenance. Many providers claiming five-nines availability will add small print to get around this problem. By excluding scheduled downtime, five-nines becomes a lot easier. > You get what you pay for. Unix maint philosophy may be acceptable on $10,000 > computers but highly unacceptable on multi-million $ computers. We don't > tolerate unintentional downtime. That doesn’t stand up to scrutiny! Just ask Air New Zealand in 2009, HSBC in 2011, or the Royal Bank of Scotland in 2013. The fact is that even five-nines availability for an entire computing service is impossible to guarantee. There is too little room for error and Black Swan or unexpected events are impossible to eliminate. If you have access to the IBM support portal go and do a search for z/OS Red Alerts. Software has bugs, applications and subsystems fail. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN