>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
