>What I see is that z/OSMF development is following the same path as all of the >other 'lets get modern' projects. You pick the pretty GUI you like and start >applying that toolset against a currently working 'solved' problem. >Promising modernization according to latest hot topics in code development. >Buzzwords come and go, languages come and go, software development kits come >and go ad infinitum. > >What tends to be forgotten are all the time and effort spent on building the >solution to the old solved problem. I can remember many discussions here and >elsewhere about ServerPac changes and difficulties that could benefit by more >development changes. > >Who remembers all the IBM and OEM 'assistance' products created to buffer us >poor feeble support teams from the evils of SMP or SMP/E. > >z/OSMF is just the latest way to 'dumb down' the complexities for the masses. > But then reality steps in. Somebody, Somewhere HAS to know what has to >happen when the rubber meets the road. And navigating from the GUI through >the stack of products to get to the Road is a long and twisted path. > >IF (a big IF) you think the same way the GUI developer thinks, then life can >get smoother. Any attempt to repeat the processes that were repeatable and >have worked before will meet resistance. > >With the removal of old options like ServerPac and being forced to the new >paradigm of z/OSMF will eventually lead to a better z/OSMF tool. But lood >for years of development just like ServerPac needed to achieve its popularity. > Amen.
If I still had to install a new z/OS version before retirement, I'd go back to CBPDO. It's a bit more work because I have to do the apply myself, but it's tried and true, and I have used CBPDO on any product we have had to install except z/OS itself (Java, the compilers, ...) Regards, Barbara Nitz ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
