A double AMEN - I have not had the luxury of time to use Z/OSMF, my TCPIP guy requested I install it for ease of managing TLS Policies, my big mistake was installing the product in my /Service directory and there it stayed for almost 2 years. a call to suppose and no help fixing my configuration mistakes, so now the ZFS file-system needs to be mounted @ /Service. No changes I've made, nor any suggestions from support could fix this issue, somewhere in the file system, buried is the mount-point and I don't have the time to investigate further where this may be. I've have had conference calls with the developers to discuss my use and my plans for 2.2, and still no offers to help me with something I think support can help with or the a developer. ?! Now I'm in the process of migration to z/OS 2.2 and went thru the task of migrating z/OSMF to 2.2, from what I see all this job did was create a new parmlib member but the address space IZUSRV1 in the new proclib does not appear to point to ANY PARMLIB's for any configuration information, so I'll wait and see my first IPL and startup of Z/osmf. documentation is lacking, at least for myself on what the migration tasks are suppose to perform. my 2 cents
Carmen ----- Original Message ----- From: "Barbara Nitz" <[email protected]> To: [email protected] Sent: Wednesday, July 12, 2017 6:50:07 AM Subject: Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES) >But is it a valid data point? We use z/OSMF only insofar as we are forced to >for IP configuration and upkeep. We did not use z/OSMF to install v2.2, and I >don't know whether we'll use it to install v2.3. There is talk of it, but it >seems to be largely motivated by the thought that we will be forced into it >(kind of like zFS). > >Don't get me wrong, we've had talks... I'm with simple and common software >management processes, and I'm glad to see ISVs on board, but I'm not convinced >that z/OSMF in and of itself is either necessary or sufficient to achieve the >goal. If you have good SMP/E packaging, z/OSMF is unnecessary as an installer. >If you have crappy SMP/E packaging, front-ending it with z/OSMF will not be >sufficient to address the shortfall. > >I don't see the need for z/OSMF for software deployment. We have plenty of >experience here, and are easily passing that along to our newer sysprogs. I >recoil at the thought of using it for configuration. ISPF is sufficient to >edit PARMLIB, et al, and it runs in a WS client, if you so choose. > >Seems to me, any of the substantive improvements offered by z/OSMF ought to be >UI-agnostic. It doesn't take a "sticky" UI and and the overhead (FSVO minimal) >of a server address space to improve product installation. These might have >been made accessible ServerPac, or even the SMP/E dialogs, but they weren't. >It's a fine thing for someone who wants the trouble of installing and >configuring Liberty et al (and I've heard the cursing all the way from Austin >and Phoenix), but ISPF apps ought to continue as supported options for those >who prefer them. Amen to that, from the bottom of my heart. I managed to configure ATTLS at z/OS 2.1 just fine without z/OSMF, and eventually understood what needs to get done and how things work together, and I will certainly not activate z/OSMF under z/OS 2.3. It will be just so much more dead weight on the sysres - together with all the useless fonts that were pushed down our throats, as far as I am concerned. >From the timetable John has sketched in that presentation - it may well be >that I will have to use the deadweight to install z/OS 2.5 in 2021. Retirement >cannot come soon enough! As far as enforcing naming conventions go - we just had that exact same discussion here when a vendor naming convention wants to enforce &sysclone. usage when that symbol has never been used here. And I am fairly sure that all the so-called simplification within z/OSMF will just take away the configuration choices that we have grown used to to make all systems look like what IBM envisions. Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
