I'd also love to see that report, - most useful for both the subject under discussion but also to use as an integrity check that the system is configured as we expect.
Jerry Whitteridge Manager Mainframe Systems & Storage Albertsons - Safeway Inc. 925 738 9443 Corporate Tieline - 89443 If you feel in control you just aren't going fast enough. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J O Skip Robinson Sent: Wednesday, December 09, 2015 3:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES2/3 Initialization member not reflecting current running system was Re: Inquire intrdr default job class I would be more than happy with a report showing any inconsistencies between the running JES2 and the actual values coded in a user-selectable init deck. Let me decide how to resolve differences, when to do it, and by whom. As I said earlier, possibly fatal differences could hide for years until the next cold start. . . . 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 Clark Morris Sent: Tuesday, December 08, 2015 6:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):JES2/3 Initialization member not reflecting current running system was Re: Inquire intrdr default job class 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 >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 "Email Firewall" made the following annotations. ------------------------------------------------------------------------------ Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately.. ============================================================================== ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
