I too use DDDEFs. I always run APPLY CHECK and ACCEPT CHECK and verify volsers and PATHs. F 'DATA SET OR PATH' eliminates any embedded volser/path from the REASON REPORT section. That way if I'm out of the office for an extended period of time and some SMP/E work needs to be done people aren't searching around for my heavily modified JCL.
Thank You ;-D an -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, May 10, 2016 12:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E Feature? I'm a firm believer in DDDEFs. In addition to the compelling reasons offered by Mark Zelden, DDDEFs make a product 'self-contained', a quality that can be invaluable to a person who has to pick up the product after the original installer/maintainer has left the fold. Trying to find all the pieces of a product can become nearly impossible if install data sets are named only in someone's personal JCL library, which may or may not be findable. I've pursued the big hunt in the past and come back to camp empty-handed. Everyone goes hungry. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Tuesday, May 10, 2016 8:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: SMP/E Feature? I never responded / commented on Andrew's post, but since you brought the subject up again I will. I always use DDDEFs unless some products install / maintenance procedures don't include adding DDDEFs and the vendor supplies an SMP/E PROC or JCL with all the DDs in them instead. Even then I may add the DDDEFs depending on how many target and dlibs there are. In my original post the example was from a product that contains JES2 exits and is of course very sensitive to the the JES2 level and /or IBM maintenance to JES2. The exits are installed in the product as a usermod and you re-apply the usermod to force reassembly after JES2 maintenance is applied. Since multiple levels of the OS are being maintained I "APPLY REDO" pointing to a copy of the SMP/E controlled loadlib using the proper level of the JES2 macro library. It makes little sense (at least to me) to run one apply, change the dddef, then run another apply for each JES2 level. It's much easier to keep two copies of the JCL with the SYSLIB override in JCL pointing to the correct macro library where I can see it. There is no "correct" DDDEF when I'm maintaining two different OS / JES2 levels. I actually have several products that I have to deal with this way while maintaining multiple OS / JES2 levels. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ On Mon, 9 May 2016 19:23:20 -0500, Edward Gould <edgould1...@comcast.net> wrote: >I will take a contrary due here. >I never did trust SMPE with DDDEFS I always coded the JCL and I always know >what libraries were being used/updated. Its too easy to make mistakes with >DDEF’s (IMO). JCL is easy and straight forward in my opinion. Especially when >you have too many fingers in the pipes (i.e. trainee’s but I have seen seniors >screw up as well. > >Ed > >> On May 5, 2016, at 6:16 PM, Andrew Rowley <and...@blackhillsoftware.com> >> wrote: >> >> On 6/05/2016 8:11, Mark Zelden wrote: >>> 1) There is a DDDEF called AAAA. It points to a DSN defined with DISP=SHR >>> (no volser / unit). >>> 2) The SYSLIB concatenation includes DDNAME AAAA (last in the >>> concatenation, I didn't >>> test a different order). >>> 3) At execution time DD AAAA is overridden in the JCL to point to a >>> different VOLSER than >>> the cataloged version. >>> 4) The data set used in the SYSLIB concatenation is the cataloged version, >>> not the override. >> >> I think it is the behaviour I would expect. >> I think the SYSLIB concatenation includes DDDEFs which specify datasets, not >> DDNAMEs. >> >> Overriding SMP/E DDDEFs via JCL always seemed to me like it was a bad thing >> to do... I always felt that the SMP/E zones should contain all the >> definitions for the installation. Overriding DDs seemed like a recipe for an >> inconsistent installation if e.g. some people did the override and others >> didn't, or if some overrides became out of date. >> >> -- >> Andrew Rowley >> Black Hill Software >> +61 413 302 386 ---------------------------------------------------------------------- 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
