Professor Skip assumes that it will be done wrong--at least in execution. Unless the design anticipates and properly handles all execution flubs, then the design is wrong. What could go wrong?
-- A faulty command is issued. If the update is echoed to the control file, the component (JES2 in this thread) might fail to come up or at least work properly at IPL time. -- A command is issued by an operator who may not even have READ access to JES2 parms, yet the content is written into the control file. -- Two or more commands are issued in quick succession--maybe by different people. What gets echoed to the control file? If you take a poll of sysprogs on whether to implement this mechanism, I doubt that many would be enthusiastic. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com OR jo.skip.robin...@att.net OR jo.skip.robin...@gmail.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, December 08, 2015 9:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Inquire intrdr default job class On 2015-12-08, at 10:05, J O Skip Robinson wrote: > When you're the only kid in the toy store, you have free reign. Even z HMC > uses the 'write-back' function for tuning updates. But z/OS is a complex > shared environment. You can't allow random process-altering commands to > update common control data sets. Recipe for chaos. > A professor in a class I took once countered such an argument with: "Why do you assume it has to be done wrong!?" Straw man. A wrong way would be for a sysadmin with a Windows-geek orientation to: o FTP a PARMLIB member to a desktop. o Edit it with Notepad. o FTP it back. In fact, it's wrong only if two of them do it at once. ISPF EDIT has some effective techniques for serializing updates to PDS members, precluding two programmers' editing the same member simultaneously. Certainly an interactive tool with a "Save as Default" capability is less chaotic than handwritten notes to operators, "When you IPL, be sure to issue all the following SET commands ..." It seems to me that having a "... great many changes ... now made simply by command ..." is equally a "[r]ecipe for chaos." Only slightly less so if the commands are embedded in a script automatically run at IPL. > > > On 2015-12-07 09:58, J O Skip Robinson wrote: >> Gil's point raises an issue more critical than just the question at hand. >> Once upon a time, 'reading JES2 parms' would have been a reasonable strategy >> in general for determining how JES2 runs. Since the advent of pervasive >> dynamic changes, however, the init deck as coded is no longer a reliable >> window into JES2 processing. A great many changes are now made simply by >> command. Old values are ignored on hot start and in many cases even on >> all-system warm start. Only a cold start will reinstate coded parm values >> that might actually be years out of date. >> >> There is today no substitute for a display command with full detail. >> > More modern systems, often on desktops, have similar dynamic change > facilities. However they often have a "Save as Default" checkbox which does > the equivalent of writing the changes back to the init deck and making them > persistent. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
