On 8 Dec 2015 14:27:38 -0800, in bit.listserv.ibm-main you wrote: >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.
As someone who did his last system programming with responsibility for JES over 25 years ago, I feel equally nervous about have a JES modified substantially from the initialization member settings by command where this situation persists over years. There should be some mechanism to bring initialization deck in line with the current operation parameters. One possibility would be a option in both JES2 and JES3 to create an initialization member from the settings in the current running system. Clark Morris > >. >. >. >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 >[email protected] >OR >[email protected] >OR >[email protected] > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On >Behalf Of Paul Gilmartin >Sent: Tuesday, December 08, 2015 9:29 AM >To: [email protected] >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 [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
