The Devil is in the details. Point-and-shoot can be a timesaver. Drag-and-drop. can be a time saver. A well designed GUI can be a pleasure to work with.
The fly in the ointment is that ease of use is not automatic, and a GUI for which the developer did not take into account all user requirements can be ghastly. Some issues for the developer to take into account: Is there a convenient migration path? Can the user easily script the GUI? Does the GUI preempt decisions that the user was previously able to make? Is there good recovery from failure? Is it easy to configure? Can it accommodate installation conventions? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Tom Longfellow <000003e29b607131-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, July 10, 2024 10:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: another z/OSMF rant. -- Catch-22 is killing me Discussions about z/OSMF (or GUIs in general) can now join the list of topics like politics and religion. Lots of yelling back and forth to defend your beliefs. You will not change the other persons mind no matter what reasoning you use. The opposing side is using arguments with assumptions and facts with which you do not agree. As the victim down here where the rubber meets the road, I am just asking questions. Why? Why is it there? Didn't the prior way do the job? What is so much better under a GUI? (GUI worshippers never even think about that one). Why are the tools now more complicated that the things they support? All GUIs are a front end to something else. Eventually, you may have to go directly to the something else to get your mission accomplished. This is not new. COBOL , C and all HLLs are all front end to assembler statements. Assember is a front end to machine code. Machine code makes the bytes move. You are not going to win friends and influence people by building a new multi-part monster that front-ends the basic function. I drank the Kool-Aid back in September and installed z/OS 2.5 using the workflows. It could build a working z/OS system. However, that system could not assume the functions performed by the current system. There is a great wide world beyond the cult compound of the IBM install process. Local exits. Vendor products. Networking. Automation. All have impacts on being able to keep your job.. The answer I get back is to build your own workflows and add them to the GUI Frankenstein's monster. My brief forway into building, testing and implementing services and workflows for local customizations had such a learning code that I could not see finishing my new install in under 6 months. My decades of local experience building repeatable, reusable JCL can complete an end to end full function installation in less that a working week. To give them 'some' credit, I can see some potential benefit if I was managing a planet wide SYSPLEX and installing portable system software instances 50 times a year. I perform a new install every 2 to 3 years on two mainframes in the USA. This is done with me and the 'other guy'. I do not have a standby cadre of experts on Liberty, JAVA, HTTPS, and the rest of the GUI world. The 'not quite Silver' lining is that it will all be over for me soon. No, I am not dying, But I have watched the death of 3 mainframes in the past year with more to come in the next year. I am old enough to retire and will probably do so. ---------------------------------------------------------------------- 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