I believe NewEra's Image Focus would reflect that in their audit reports. I thought it was a really cool product when I was able to use it.
On Wed, Dec 9, 2015 at 5:23 PM, Jerry Whitteridge < [email protected]> wrote: > 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:[email protected]] On > Behalf Of J O Skip Robinson > Sent: Wednesday, December 09, 2015 3:17 PM > To: [email protected] > 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 > [email protected] > OR > [email protected] > OR > [email protected] > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Clark Morris > Sent: Tuesday, December 08, 2015 6:42 PM > To: [email protected] > 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 > >[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 > > "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 [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
