One issue is that z/OSMF is expensive in CPU. I noticed in the system trace, that there are 500 storage requests (eg getmain/freemain) for each http rest message coming in. Getting rid of these expensive requests would reduce the costs. I think all of these come from below the Java level, such as BPX* modules. For example, write an SMF record from C requires a getmain .. write SMF record - free main.
Ive blogged <https://colinpaice.blog/2020/12/21/a-practical-guide-to-getting-z-osmf-working/> on getting z/OSMF working including digital certificates. Unfortunately I dont think they have designed it properly. Other products have the "keystore" (keyring), containing just the private key for the server, and the "trust store" (keyring) containing the public certificate needed to validate any certificates sent to the server. This trust store can be used by all products (Sysplex wide). z/OSMF just uses one, combined, store(keying). This means I cant just reuse my existing certificate set up, and so I have to have a dedicated keyring for each z/OSMF. This makes the setup much harder, and makes administration hard. It is not much code to fix it ( I implemented it in my Java server). I think that z/OSMF could be great for the younger generations to get up to speed. But it needs to be improved to make it low cost and easy to install and configure (as in get it into production, rather than just get it started). Colin On Sat, 17 Jul 2021 at 11:47, Brian Westerman <brian_wester...@syzygyinc.com> wrote: > Hi Cheryl, I had a similar discussion with you about a year ago, and IBM > contacted me to get more information on the "problem". For me, getting > z/OSMF setup and running was not an issue, except for the fact that there > wasn't enough processing power to keep it running properly. > > Unfortunately for a small shop, and we maintain several of them, the > ability to run z/OSMF is just not there. I had a very long back and forth > with IBM about this and once they figured out that the two "sample" sites I > was dealing with were z13s (80mip) and a z15t02 (88mip), they decided that > they needed to republish the "minimum" requirements. If you look at the > guide now, they use a 400+mip box to do the setup and testing. I still > have the information from them if you are interested, but once they finally > understood, and agreed, that there are some sites that just "can't", or > "won't be able to" run it, they dropped the issue and just stopped > talking. However, he did agree that it would be VERY difficult, if not > impossible, to try to use z/OSMF on an 80mip box, especially the one they > have with 4 LPARs. > > Asking a site that is able to function within their requirements and > existing SLA's to upgrade their box to more than 4x the existing size just > to run z/OSMF is just never going to be economically feasible. Even on > sites with larger machines, they may not have the extra capacity to provide > z/OSMF with what it needs to function properly. > > Currently, z/OSMF is not a one-size-fits-all solution for installation of > z/OS, at least not for the smaller shops. > > Brian > > > On Fri, 16 Jul 2021 22:25:49 -0400, Cheryl Watson Walker < > che...@watsonwalker.com> wrote: > > >Hi Terri, > > > >I understand your situation, but I hope you will reconsider one of your > >earlier statement: "never touch z/OSMF again for 2 years." Yes, z/OSMF > has > >had some problems, but it is absolutely IBM's direction and new > >functions/facilities are being added to z/OSMF all the time. As one of > your > >site's senior people, I think it would be to your benefit to ensure that > >your entire staff is familiar with the tool. As an ISV, you are probably > in > >the PartnerWorld ISV group and see that other software vendors are > creating > >installation workflows for their own software. Even as a small software > >provider, we're looking at doing the same thing. > > > >I think that it is a shame that the bad experiences, such as with > >certificates, have kept many installations from exploiting the powerful > >features of z/OSMF. One small example that I heard a couple of weeks ago > >was a site who finally went to z/OSMF in production and discovered that > WLM > >under z/OSMF provides an edit facility to show if something is incorrect. > >The person said: "where has this been all my life?". So I hope that other > >sites will not let a bad experience keep them from trying it again. > > > >Best regards, > >Cheryl > > > >====================== > >Cheryl Watson Walker, CEO > >Watson & Walker, Inc. > >Sarasota, FL USA > >www.watsonwalker.com > >====================== > > > > > > > >-----Original Message----- > >From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of > >Shaffer, Terri > >Sent: Friday, July 16, 2021 7:07 PM > >To: IBM-MAIN@LISTSERV.UA.EDU > >Subject: Re: Serverpac installs January 2022 and beyond > > > >So I have to politely disagree with that comment. > > > >z/OSMF software install has always had its limitations as with big > >installation we installed once and replicated 127 times to all our other > >lpars. Now in my small shop its only 7 times, but I maintain 3 different > >levels of z/OS since we develop mainframe software. > > > >So yes huge learning curve, in-fact even serverpac has a few nuances when > it > >comes to certain system layouts, where parmlib's, proclibs, TCPIP and > other > >"system datasets' live and tweaking of the recatDS jobs to ummmm fix > things. > > > >I never said I will not try it and see, but yes my fall-back is Serverpac > at > >least one more time, for the reasons I mentioned below. I have been apart > of > >a few ESP's with IBM, so I am open to ideas. > > > >Over my 38 years doing MVS system programming, Serverpac was a slice of > >heaven, once a few modifications where allowed and I didn't have to use > the > >manual hacks modifying CPAC SLIB entries for over-rides. > > > >My comments where directed at usability, layouts, the ability to perform a > >system layout that matches my current environments, and the list goes on. > > > >I like having the control before I submit a job, completely understanding > >what is does, because the thing I hate is opps after I hit enter. > > > >Also the setup for certificates, especially on corporate PC's, with no > ADMIN > >rights or a defined process to manage, adds to my concerns and issues. > > > >Ms Terri E Shaffer > >Senior Systems Engineer, > >z/OS Support: > >ACIWorldwide - Telecommuter > >H(412-766-2697) C(412-519-2592) > >terri.shaf...@aciworldwide.com > > > >-----Original Message----- > >From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of > >Richards, Robert B. (CTR) > >Sent: Friday, July 16, 2021 12:40 PM > >To: IBM-MAIN@LISTSERV.UA.EDU > >Subject: Re: Serverpac installs January 2022 and beyond > > > >External Email > > > > > >This level of vitriol is best left to twitter, fb or Instagram. > > > >It is totally uncalled for on this list. Every new process has its bumps > and > >bruises and after twenty years, ServerPac was overdue for a makeover. > > > >Just my two cents. > > > >-----Original Message----- > >From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of > >Ron Wells > >Sent: Friday, July 16, 2021 12:06 PM > >To: IBM-MAIN@LISTSERV.UA.EDU > >Subject: Re: Serverpac installs January 2022 and beyond > > > >Total joke--setup and developed by people that THINK they know what they > are > >doing and THINK they know what you need. > > > >-----Original Message----- > >From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of > >Shaffer, Terri > >Sent: Friday, July 16, 2021 11:01 AM > >To: IBM-MAIN@LISTSERV.UA.EDU > >Subject: Re: Serverpac installs January 2022 and beyond > > > >** EXTERNAL EMAIL - USE CAUTION ** > > > > > >So not to beat up on this new installation process, but if I have the > option > >on installing z/OS 2.5 with serverpac in Oct, I will never touch z/OSMF > >again for 2 years. > > > >It took me 2 days and working with security just to get the certificates > >working correctly. I still have issues with the HTTPS not authenticating, > >but at least z/OSMF can communicate with my LPARS. > > > >Then I tried the TRYIT - Portable software instance and looks like even > more > >issues, or things that haven't been customized. Because I don't use ISP, > >HLQ's > > > >An error occurred on system "ACWA". Error: "login: timeout: > >TsoServerConnection(USER=TSSTESA, ASID=0x00b5, QID=0x00000019)". > "IKJ56455I > >TSSTESA LOGON IN PROGRESS AT 10:49:05 ON JULY 16, 2021 IEFA107I TSSTESA > >IZUFPROC IZUFPROC SYSEXEC - DATA SET ISP.SISPEXEC NOT FOUND ". The error > >report returned by the z/OS data set and files REST interface for the > >"LIST_DATASETS" service contains category "2", return code 4 and reason 1. > > > >For the migration guide I will explode/print because using z/OSMF on a > >window that is about 8 x 5 is un-usable, with all the z/OSMF headers and > >tabs, etc. > > > >If IBM wanted to fix this SPAWN another window to view the Migration task > at > >least then it would be the size of my laptop monitor. > > > >I understand IBM's direction but just like many shops have stated we never > >start it, I just setup a JCL error in the proc and go about it not taking > >130G of storage and resources. > > > >Ms Terri E Shaffer > >Senior Systems Engineer, > >z/OS Support: > >ACIWorldwide - Telecommuter > >H(412-766-2697) C(412-519-2592) > >terri.shaf...@aciworldwide.com > > > >-----Original Message----- > >From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of > >Marna WALLE > >Sent: Sunday, March 7, 2021 10:28 AM > >To: IBM-MAIN@LISTSERV.UA.EDU > >Subject: Re: Serverpac installs January 2022 and beyond > > > >External Email > > > > > >Brian, > >I would like to assure you that this decision was not taken lightly, and > was > >taken with all those considerations (and others) to extend both ordering > >types for as long as was feasible. > > > >Some points I would like to make: > > > >- the z/OS ServerPac for z/OSMF is extremely similar to the CICS, Db2,and > >IMS ServerPac for z/OSMF. What is different? The Workflows which contain > >the configuration and verification, since they are product-specific. > Where > >can you see those Workflow steps today? By looking at your z/OS CustomPac > >dialog JCL jobs you ran for your last z/OS installation. Those are the > >Workflow steps you'll see. So the "differences" are simply the way you > >submit the JCL jobs. Do you want to see how you lay down the data sets > and > >assign them to volumes and catalogs, and how that is different with z/OSMF > >vs. ISPF? Look today at the CICS, IMS, and Db2 z/OSMF ServerPac. That is > >how it will be done - with the z/OS addition that you'll be able to use > (or > >not use) a new master catalog, as you desire. > > > >- providing a "dual" method of installing the z/OS release (and other IBM > >products) requires two software manufacturing processes, for existing and > >every new product that GA's during that time. I'm sure I don't need to > >mention that the costs of have two production processes for every product > in > >the IBM catalog is not insignificant. Now, that is what we are doing > right > >now for CICS, IMS, and Db2, so that customers can have that choice right > now > >for the non-z038 SREL products. It is expected that you set up and learn > >this process now, so that when the z/OS SREL arrives, it is not a unknown > >method of installing. Keep in mind, these "dual" paths and costs have > been > >ongoing since September 2019. This overlap has been going on for a while, > >at varying levels for the product set. > > > >- As you mention, if you still want to see z/OS itself in z/OSMF > ServerPac, > >then order z/OS V2.5 between Sept 2021 and January 2022. Install it. > Throw > >it away. That would then be your "test order". That is how it will > >install should you re-order z/OS V2.5 (or a later release) when you are > >ready to install it. > > > >- You mention that the service on the ServerPac, if you keep it > >un-installled, will need more PTFs. Yes, if you insist that you must > install > >a CustomPac ServerPac after that path is gone, it will age as any old > >ServerPac order will age. This is no different than ordering a z/OS > release > >in ServerPac before it is end-of-marketing, putting it on the shelf, and > >having to install many PTFs today. I've seen lots of customers do that for > >z/OS V2.3, when they were on V2.1 and weren't ready to move yet. Always, > I > >recommend that if your z/OS release is still orderable and yours has aged, > >order another one with current service. > > > >- You mention anyone running below z/OS V2.3, will have a harder path to > >z/OS V2.5. I would say that anyone on V2.2 or lower, wishing to go to > z/OS > >V2.5, will have a harder path if they don't stay within the coexistence > >policy, and are not service supported. And this has little to do with how > >the ServerPac is packaged. I know you are involved in quite a few of > those > >"long jumps" and all of the added complications they bring since there is > no > >coexistence support, but I don't think that using z/OSMF to install V2.5 > >will be one of those largest concerns. Many of the installation and > >configuration enhancements were rolled back pre-V2.3 when they were > >released. I would install all the z/OSMF PTFs on those older systems to > >help as much as possible to get z/OSMF Software Management and Workflows > up > >and running on the sandbox driving system. That should be done right now, > >unless the Customized Offering Driver (COD) is the better (and longer) > path > >for the situation. Customers on V2.2 should be going to V2.4, which is > >orderable right now - do not delay. So, for z/OS V2.2 customers, I see no > >z/OSMF requirement impediment. > > > >-Marna WALLE > >z/OS System Installation and Upgrade > >IBM Poughkeepsie > > > > > > > > > >- > > > >---------------------------------------------------------------------- > >For IBM-MAIN subscribe / signoff / archive access instructions, send email > >to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >________________________________ > >[ > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgo.aciwor > >ldwide.com > %2Frs%2F030-ROK-804%2Fimages%2Faci-footer.jpg&data=04%7C01%7CR > >on.Wells%40OMF.COM > %7C12ccaad96a574710e20c08d94872fb35%7C57c0053cb5f84a1e8bb6 > > >e8afa09f3b82%7C0%7C0%7C637620480946226340%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > > >4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=im > >5eiadNM%2FE2bkqlNRCM%2FNP42jK0DiaGaGf%2BIFmoSu4%3D&reserved=0] > >< > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.aciwor > >ldwide.com%2F&data=04%7C01%7CRon.Wells%40OMF.COM > %7C12ccaad96a574710e20c0 > > >8d94872fb35%7C57c0053cb5f84a1e8bb6e8afa09f3b82%7C0%7C0%7C637620480946226340% > > >7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi > > >LCJXVCI6Mn0%3D%7C1000&sdata=YbR0t%2BuDUbjgd8EtxzVezBua3NVItuUGiYZtXayLls > >A%3D&reserved=0> > >This email message and any attachments may contain confidential, > proprietary > >or non-public information. The information is intended solely for the > >designated recipient(s). If an addressing or transmission error has > >misdirected this email, please notify the sender immediately and destroy > >this email. Any review, dissemination, use or reliance upon this > information > >by unintended recipients is prohibited. Any opinions expressed in this > email > >are those of the author personally. > > > >---------------------------------------------------------------------- > >For IBM-MAIN subscribe / signoff / archive access instructions, send email > >to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > >Email Disclaimer > > > >This E-mail contains confidential information belonging to the sender, > which > >may be legally privileged information. This information is intended only > for > >the use of the individual or entity addressed above. If you are not the > >intended recipient, or an employee or agent responsible for delivering it > to > >the intended recipient, you are hereby notified that any disclosure, > >copying, distribution, or the taking of any action in reliance on the > >contents of the E-mail or attached files is strictly prohibited. > > > >---------------------------------------------------------------------- > >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 > >________________________________ > >[https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] > ><http://www.aciworldwide.com> This email message and any attachments may > >contain confidential, proprietary or non-public information. The > information > >is intended solely for the designated recipient(s). If an addressing or > >transmission error has misdirected this email, please notify the sender > >immediately and destroy this email. Any review, dissemination, use or > >reliance upon this information by unintended recipients is prohibited. Any > >opinions expressed in this email are those of the author personally. > > > >---------------------------------------------------------------------- > >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
